View M82380_1909161.PDF datasheet online --- IC-ON-LINE

Datasheet File OCR Text:

november 1992 order number: 271070-006 M82380 high performance 32-bit dma controller with integrated system support peripherals y high performance 32-bit dma controller e 40 mbytes/sec maximum data transfer rate at 20 mhz e 8 independently programmable channels y 20-source interrupt controller e individually programmable interrupt vectors e 15 external, 5 internal interrupts e m8259a superset y four 16-bit programmable interval timers e m82c54 compatible y programmable wait state generator e 0 to 15 wait states pipelined e 1 to 16 wait states non-pipelined y dram refresh controller y i386 tm processor shutdown detect and reset control e software/hardware reset y high speed chmos iii technology y 132-pin pga package and 164-pin quad flat pack (see packaging specification order y 231369) y optimized for use with the i386 tm microprocessor e resides on local bus for maximum bus bandwidth y available in three product grades: e mil-std-883, b 55 cto a 125 c(t c ) e military temperature only, b 55 cto a 125 c(t c ) e extended temperature, b 40 cto a 110 c(t c ) the M82380 is a multi-function support peripheral that integrates system functions necessary in an i386 processor environment. it has eight channels of high performance 32-bit dma with the most efficient transfer rates possible on the i386 microprocessor bus. system support peripherals integrated into the M82380 provide interrupt control, timers, wait state generation, dram refresh control, and system reset logic. the M82380's dma controller can transfer data between devices of different data path widths using a single channel. each dma channel operates independently in any of several modes. each channel has a temporary data storage register for handling non-aligned data without the need for external alignment logic. 271070 1 M82380 internal block diagram
M82380 M82380 high performance 32-bit dma controller with integrated system support peripherals contents page 1.0 functional overview 6 1.1 M82380 architecture 6 1.1.1 dma controller 7 1.1.2 programmable interval timers 8 1.1.3 interrupt controller 9 1.1.4 wait state generator 10 1.1.5 dram refresh controller 10 1.1.6 cpu reset function 11 1.1.7 register map relocation 11 1.2 host interface 11 2.0 i386 tm processor host interface 12 2.1 master and slave modes 13 2.2 m80386 interface signals 13 2.2.1 clock (clk2) 13 2.2.2 data bus (d0 d31) 13 2.2.3 address bus (a31 a2) 14 2.2.4 byte enable (be3 be0 ) 14 2.2.5 bus cycle definition signals (d/c , w/r , m/io ) 15 2.2.6 address status (ads ) 15 2.2.7 transfer acknowledge (ready ) 15 2.2.8 next address request (na ) 15 2.2.9 reset (reset, cpurst) 15 2.2.10 interrupt out (int) 17 2.3 M82380 bus timing 17 2.3.1 address pipelining 17 2.3.2 master mode bus timing 17 2.3.3 slave mode bus timing 20 3.0 dma controller 21 3.1 functional description 22 3.2 interface signals 23 3.2.1 dreqn and edack (0 2) 24 3.2.2 hold and hlda 24 3.2.3 eop 24 3.3 modes of operation 24 3.3.1 target/requester definition 25 3.3.2 buffer transfer processes 25 3.3.3 data transfer modes 26 3.3.4 channel priority arbitration 30 3.3.5 combining priority modes 32 3.3.6 bus operation 33 3.4 bus arbitration and handshaking 34 3.4.1 synchronous and asynchronous sampling of dreqn and eop 37 3.4.2 arbitration of cascaded master requests 39 3.4.3 arbitration of refresh requests 41 2
M82380 contents page 3.0 dma controller (continued) 3.5 dma controller register overview 41 3.5.1 control/status registers 41 3.5.2 channel registers 42 3.5.3 temporary registers 43 3.6 dma controller programming 44 3.6.1 buffer processes 44 3.6.2 data transfer modes 45 3.6.3 cascaded bus masters 45 3.6.4 software commands 45 3.7 register definitions 46 4.0 programmable interrupt controller 53 4.1 functional description 53 4.1.1 internal block diagram 53 4.1.2 interrupt controller banks 54 4.2 interface signals 55 4.2.1 interrupt inputs 55 4.2.2 interrupt output (int) 56 4.3 bus functional description 56 4.4 mode of operation 57 4.4.1 end-of-interrupt 57 4.4.2 interrupt priorities 58 4.4.3 interrupt masking 61 4.4.4 edge or level interrupt triggering 61 4.4.5 interrupt cascading 61 4.4.6 reading interrupt status 62 4.5 register set overview 62 4.5.1 initialization command words (icw) 64 4.5.2 operation control words (ocw) 64 4.5.3 poll/interrupt request/in-service status register 65 4.5.4 interrupt mask register (imr) 65 4.5.5 vector register (vr) 65 4.6 programming 65 4.6.1 initialization (icw) 65 4.6.2 vector registers (vr) 66 4.6.3 operation control words (ocw) 66 4.7 register bit definition 67 4.8 register operational summary 70 3
M82380 contents page 5.0 programmable interval timer 71 5.1 functional description 71 5.1.1 internal architecture 72 5.2 interface signals 73 5.2.1 clkin 73 5.2.2 tout1, tout2 , tout3 73 5.2.3 gate 73 5.3 modes of operation 74 5.3.1 mode 0einterrupt on terminal count 74 5.3.2 mode 1egate retriggerable one-shot 74 5.3.3 mode 2erate generator 76 5.3.4 mode 3esquare wave generator 77 5.3.5 mode 4einitial count triggered strobe 79 5.3.6 mode 5egate retriggerable strobe 80 5.3.7 operation common to all modes 81 5.4 register set overview 81 5.4.1 counter 0, 1, 2, 3 registers 82 5.4.2 control word registe ri&ii 82 5.5 programming 82 5.5.1 initialization 82 5.5.2 read operation 82 5.6 register bit definitions 84 6.0 wait state generator 86 6.1 functional description 86 6.2 interface signals 87 6.2.1 ready 87 6.2.2 readyo 87 6.2.3 wsc(0 1) 87 6.3 bus function 88 6.3.1 wait states in non-pipelined cycle 88 6.3.2 wait states in pipelined cycle 89 6.3.3 extending and early terminating bus cycle 90 6.4 register set overview 91 6.5 programming 92 6.6 register bit definition 92 6.7 application issues 92 6.7.1 external `ready' control logic 92 7.0 dram refresh controller 94 7.1 functional description 94 7.2 interface signals 94 7.2.1 tout1/ref 94 7.3 bus function 95 7.3.1 arbitration 95 7.4 modes of operation 95 7.4.1 word size and refresh address counter 95 7.5 register set overview 96 7.6 programming 96 7.7 register bit definition 96 4
M82380 contents page 8.0 relocation register and address decode 96 8.1 relocation register 96 8.1.1 i/o-mapped M82380 97 8.1.2 memory-mapped M82380 97 8.2 address decoding 97 9.0 cpu reset and shutdown detect 97 9.1 hardware reset 97 9.2 software reset 97 9.3 shutdown detect 98 10.0 internal control and diagnostic ports 98 10.1 internal control port 98 10.2 diagnostic ports 98 11.0 intel reserved i/o ports 99 12.0 mechanical data 100 12.1 pin assignment 100 12.2 package dimensions and mounting 102 13.0 electrical data 104 13.1 power and grounding 104 13.2 power decoupling 104 13.3 unused pin recommendations 104 13.4 ice tm -386 support 104 13.5 maximum ratings 105 13.6 dc specifications 106 13.7 ac specifications 107 appendix aeports listed by address a-1 appendix beports listed by function b-1 appendix cepin descriptions c-1 appendix deM82380 system notes d-1 5
M82380 1.0 functional overview the M82380 contains several independent function- al modules. the following is a brief discussion of the components and features of the M82380. each module has a corresponding detailed section later in this data sheet. those sections should be referred to for design and programming information. 1.1 M82380 architecture the M82380 is comprised of several computer sys- tem functions that are normally found in separate lsi and vlsi components. these include: a high- performance, eight-channel, 32-bit direct memory access controller; a 20-level programmable inter- rupt controller which is a superset of the m8259a; four 16-bit programmable interval timers which are functionally equivalent to the m82c54 timers; a dram refresh controller; a programmable wait state generator; and system reset logic. the inter- face to the M82380 is optimized for high-perform- ance operation with the i386 microprocessor. the M82380 operates directly on the i386 micro- processor bus. in the slave mode, it monitors the state of the processor at all times and acts or idles according to the commands of the host. it monitors the address pipeline status and generates the pro- grammed number of wait states for the device being accessed. the M82380 also has logic to reset the i386 microprocessor via hardware or software reset requests and processor shutdown status. after a system reset, the M82380 is in the slave mode. it appears to the system as an i/o device. it becomes a bus master when it is performing dma transfers. to maintain compatibility with existing software, the registers within the M82380 are accessed as bytes. if the internal logic of the M82380 requires a delay before another access by the processor, wait states are automatically inserted into the access cycle. this allows the programmer to write initialization rou- tines, etc. without regard to hardware recovery times. figure 1 shows the basic architectural components of the M82380. the following sections briefly dis- cuss the architecture and function of each of the distinct sections of the M82380. 271070 2 figure 1. architecture of the M82380 6
M82380 1.1.1 dma controller the M82380 contains a high-performance, 8-chan- nel, 32-bit dma controller. it is capable of transfer- ring any combination of bytes, words, and double words. the addresses of both source and destina- tion can be independently incremented, decrement- ed or held constant, and cover the entire 32-bit physical address space of the i386 microprocessor. it can disassemble and assemble misaligned data via a 32-bit internal temporary data storage register. data transferred between devices of different data path widths can also be assembled and disassem- bled using the internal temporary data storage regis- ter. the dma controller can also transfer aligned data between i/o and memory on the fly, allowing data transfer rates up to 32 megabytes per second for an M82380 operating at 16 mhz. figure 2 illus- trates the functional components of the dma con- troller. there are twenty-four general status and command registers in the M82380 dma controller. through these registers any of the channels may be pro- grammed into any of the possible modes. the oper- ating modes of any one channel are independent of the operation of the other channels. each channel has three programmable registers which determine the location and amount of data to be transferred: byte count registerenumber of bytes to trans- fer. (24-bits) requester registereaddress of memory or pe- ripheral which is requesting dma service. (32- bits) target registereaddress of peripheral or mem- ory which will be accessed. (32-bits) there are also port addresses which, when ac- cessed, cause the M82380 to perform specific func- tions. the actual data written does not matter, the act of writing to the specific address causes the command to be executed. the commands which op- erate in this mode are: master clear, clear terminal count interrupt request, clear mask register, and clear byte pointer flip-flop. dma transfers can be done between all combina- tions of memory and i/o; memory-to-memory, mem- ory-to-i/o, i/o-to-memory, and i/o-to-i/o. dma service can be requested through software and/or hardware. hardware dma acknowledge signals are available for all channels (except channel 4) through an encoded 3-bit dma acknowledge bus (edack0 2). 271070 3 figure 2. M82380 dma controller 7
M82380 the M82380 dma controller transfers blocks of data (buffers) in three modes: single buffer, buffer auto- initialize, and buffer chaining. in the single buffer process, the M82380 dma controller is pro- grammed to transfer one particular block of data. successive transfers then require reprogramming of the dma channel. single buffer transfers are useful in systems where it is known at the time the transfer begins what quantity of data is to be transferred, and there is a contiguous block of data area available. the buffer auto-initialize process allows the same data area to be used for successive dma transfers without having to reprogram the channel. the buffer chaining process allows a program to specify a list of buffer transfers to be executed. the M82380 dma controller, through interrupt routines, is reprogrammed from the list. the channel is repro- grammed for a new buffer before the current buffer transfer is complete. this pipelining of the channel programming process allows the system to allocate non-contiguous blocks of data storage space, and transfer all of the data with one dma process. the buffers that make up the chain do not have to be in contiguous locations. channel priority can be fixed or rotating. fixed priori- ty allows the programmer to define the priority of dma channels based on hardware or other fixed pa- rameters. rotating priority is used to provide periph- erals access to the bus on a shared basis. with fixed priority, the programmer can set any channel to have the current lowest priority. this al- lows the user to reset or manually rotate the priority schedule without reprogramming the command reg- isters. 1.1.2 programmable interval timers four 16-bit programmable interval timers reside within the M82380. these timers are identical in function to the timers in the m82c54 programmable interval timer. all four of the timers share a common clock input which can be independent of the system clock. the timers are capable of operating in six dif- ferent modes. in all of the modes, the current count can be latched and read by the i386 processor at any time, making these very versatile event timers. figure 3 shows the functional components of the programmable interval timers. the outputs of the timers are directed to key system functions, making system design simpler. timer 0 is routed directly to an interrupt input and is not avail- able externally. this timer would typically be used to generate time-keeping interrupts. timers 1 and 2 have outputs which are available for general timer/counter purposes as well as special functions. timer 1 is routed to the refresh control logic to provide refresh timing. timer 2 is connected to an interrupt request input to provide other timer functions. timer 3 is a general purpose timer/coun- ter whose output is available to external hardware. it is also connected internally to the interrupt request which defaults to the highest priority (irq0). 271070 4 figure 3. programmable interval timerseblock diagram 8
M82380 1.1.3 interrupt controller the M82380 has the equivalent of three enhanced m8259a programmable interrupt controllers. these controllers can all be operated in the master mode, but the priority is always as if they were cascaded. there are 15 interrupt request inputs provided for the user, all of which can be inputs from external slave interrupt controllers. cascading m8259as to these request inputs allows a possible total of 120 external interrupt requests. figure 4 is a block dia- gram of the M82380 interrupt controller. each of the interrupt request inputs can be individu- ally programmed with its own interrupt vector, allow- ing more flexibility in interrupt vector mapping than was available with the m8259a. an interrupt is pro- vided to alert the system that an attempt is being made to program the vectors in the method of the m8259a. this provides compatibility of existing soft- ware that used the m8259a with new designs using the M82380. in the event of an unrequested or otherwise errone- ous interrupt acknowledge cycle, the M82380 inter- rupt controller issues a default vector. this vector, programmed by the system software, will alert the system of unsolicited interrupts of the m80386. the functions of the M82380 interrupt controller are identical to the m8259a, except in regards to pro- gramming the interrupt vectors as mentioned above. interrupt request inputs are programmable as either edge or level triggered and are software maskable. priority can be either fixed or rotating and interrupt requests can be nested. 271070 5 figure 4. M82380 interrupt controllereblock diagram 9
M82380 enhancements are added to the M82380 for cas- cading external interrupt controllers. master to slave handshaking takes place on the data bus, instead of dedicated cascade lines. 1.1.4 wait state generator the wait state generator is a programmable ready generation circuit for the i386 processor bus. a peripheral requiring wait states can request the wait state generator to hold the processor's ready input inactive for a predetermined number of bus states. six different wait state counts can be programmed into the wait state generator by soft- ware; three for memory accesses and three for i/o accesses. a block diagram of the M82380 wait state generator is shown in figure 5. the peripheral being accessed selects the required wait state count by placing a code on a 2-bit wait state select bus. this code along with the m/io sig- nal from the bus master is used to select one of six internal 4-bit wait state registers which has been programmed with the desired number of wait states. from zero to fifteen wait states can be programmed into the wait state registers. the wait state genera- tor tracks the state of the processor or current bus master at all times, regardless of which device is the current bus master and regardless of whether or not the wait state generator is currently active. the M82380 wait state generator is disabled by making the select inputs both high. this allows hard- ware which is intelligent enough to generate its own ready signal to be accessed without penalty. as pre- viously mentioned, deselecting the wait state gen- erator does not disable its ability to determine the proper number of wait states due to pipeline status in subsequent bus cycles. the number of wait states inserted into a pipelined bus cycle is the value in the selected wait state reg- ister. if the bus master is operating in the non-pipe- lined mode, the wait state generator will increase the number of wait states inserted into the bus cycle by one. on reset, the wait state generator's registers are loaded with the value ffh, giving the maximum number of wait states for any access in which the wait state select inputs are active. 1.1.5 dram refresh controller the M82380 dram refresh controller consists of a 24-bit refresh address counter and bus arbitration logic. the output of timer 1 is used to periodically request a refresh cycle. when the controller re- ceives the request, it requests access to the system bus through the hold signal. when bus control is acknowledged by the processor or current bus mas- ter, the refresh controller executes a memory read operation at the address currently in the refresh ad- dress register. at the same time, it activates a re- fresh signal (ref ) that the memory uses to force a refresh instead of a normal read. control of the bus is transferred to the processor at the completion of this cycle. typically a refresh cycle will take six clock cycles to execute on an i386 processor bus. 271070 6 figure 5. M82380 wait state generatoreblock diagram 10
M82380 the M82380 dram refresh controller has the high- est priority when requesting bus access and will in- terrupt any active dma process. this allows large blocks of data to be moved by the dma controller without affecting the refresh function. also the dma controller is not required to completely relinquish the bus, the refresh controller simply steals a bus cycle between dma accesses. the amount by which the refresh address is incre- mented is programmable to allow for different bus widths and memory bank arrangements. 1.1.6 cpu reset function the M82380 contains a special reset function which can respond to hardware reset signals from the m82384, as well as a software reset command. the circuit will hold the i386 processor's reset line ac- tive while an external hardware reset signal is pres- ent at its reset input. it can also reset the i386 processor as the result of a software command. the software reset command causes the M82380 to hold the processor's reset line active for a mini- mum of 62 clk2 cycles; enough time to allow an m80386 to re-initialize. the M82380 can be programmed to sense the shut- down detect code on the status lines from the m80386. if the shutdown detect function is enabled, the M82380 will automatically reset the processor. a diagnostic register is available which can be used to determine the cause of reset. 1.1.7 register map relocation after a hardware reset, the internal registers of the M82380 are located in i/o space beginning at port address 0000h. the map of the M82380's registers is relocatable via a software command. the default mapping places the M82380 between i/o address- es 0000h and 00dbh. the relocation register allows this map to be moved to any even 256-byte bounda- ry in the processor's 16-bit i/o address space or any even 16-mbyte boundary in the 32-bit memory ad- dress space. 1.2 host interface the M82380 is designed to operate efficiently on the local bus of an m80386 microprocessor. the control signals of the M82380 are identical in function to those of the i386 processor. as a slave, the M82380 operates with all of the features available on the i386 processor bus. when the M82380 is in the mas- ter mode, it looks identical to the i386 processor to the connected devices. the M82380 monitors the bus at all times, and de- termines whether the current bus cycle is a pipelined or non-pipelined access. all of the status signals of the processor are monitored. the control, status, and data registers within the M82380 are located at fixed addresses relative to each other, but the group can be relocated to either memory or i/o space and to different locations with- in those spaces. as a slave device, the M82380 monitors the con- trol/status lines of the cpu. the M82380 will gener- ate all of the wait states it needs whenever it is ac- cessed. this allows the programmer the freedom of accessing M82380 registers without having to insert nops in the program to wait for slower M82380 in- ternal registers. the M82380 can determine if a current bus cycle is a pipelined or a non-pipelined cycle. it does this by monitoring the ads and ready signals and thereby keeping track of the current state of the i386 proces- sor. as a bus master, the M82380 looks like an i386 processor to the rest of the system. this enables the designer greater flexibility in systems which include the M82380. the designer does not have to alter the interfaces of any peripherals designed to operate with the i386 processor to accommodate the M82380. the M82380 will access any peripherals on the bus in the same manner as the i386 processor, including recognizing pipelined bus cycles. the M82380 is accessed as an 8-bit peripheral. this is done to maintain compatibility with existing system architectures and software. the i386 processor places the data of all 8-bit accesses either on d (0 7) or d (8 15). the M82380 will only accept data on these lines when in the slave mode. when in the master mode, the M82380 is a full 32-bit machine, sending and receiving data in the same manner as the i386 processor. 11
M82380 2.0 i386 tm processor host interface the M82380 contains a set of interface signals to operate efficiently with the i386 host processor. these signals were designed so that minimal hard- ware is needed to connect the M82380 to the i386 processor. figure 6 depicts a typical system configuration with the i386 processor. as shown in the diagram, the M82380 is designed to interface directly with the i386 bus. since the M82380 is residing on the opposite side of the data bus transceiver (with respect to the rest of the peripherals in the system), it is important to note that the transceiver should be controlled so that contention between the data bus transceiver and the M82380 will not occur. in order to do this, port address decoding logic should be included in the di- rection and enable control logic of the transceiver. when any of the M82380 internal registers is read, the data bus transceiver should be disabled so that only the M82380 will drive the local bus. this section describes the basic bus functions of the M82380 to show how this device interacts with the i386 processor. other signals which are not directly related to the host interface will be discussed in their associated functional block description. 271070 7 figure 6. i386 tm /M82380 system configuration 12
M82380 2.1 master and slave modes at any time, the M82380 acts as either a slave de- vice or a master device in the system. upon reset, the M82380 will be in the slave mode. in this mode, the i386 processor can read/write into the M82380 internal registers. initialization information may be programmed into the M82380 during slave mode. when dma service (including dram refresh cycles generated by the M82380) is requested, the M82380 will request and subsequently get control of the i386 processor local bus. this is done through the hold and hlda (hold acknowledge) signals. when the i386 processor responds by asserting the hlda sig- nal, the M82380 will switch into master mode and perform dma transfers. in this mode, the M82380 is the bus master of the system. it can read/write data from/to memory and peripheral devices. the M82380 will return to the slave mode upon comple- tion of dma transfers, or when hlda is negated. 2.2 m80386 interface signals as mentioned in the architecture section, the bus interface module of the M82380 (see figure 1) con- tains signals that are directly connected to the i386 host processor. this module has separate 32-bit data and address busses. also, it has additional control signals to support different bus operations on the system. by residing on the i386 processor local bus, the M82380 shares the same address, data and control lines with the processor. the fol- lowing subsections discuss the signals which inter- face to the i386 host processor. 2.2.1 clock (clk2) the clk2 input provides fundamental timing for the M82380. it is divided by two internally to generate the M82380 internal clock. therefore, clk2 should be driven with twice the i386's frequency. in order to maintain synchronization with the i386 host proces- sor, the M82380 and the i386 processor should share a common clock source. the internal clock consists of two phases: phi1 and phi2. each clk2 period is a phase of the internal clock. phi2 is usually used to sample input and set up internal signals and phi1 is for latching internal data. figure 7 illustrates the relationship of clk2 and the M82380 internal clock signals. the cpurst signal generated by the M82380 guarantees that the i386 processor will wake up in phase with phi1. 2.2.2 data bus (d0 d31) this 32-bit three-state bidirectional bus provides a general purpose data path between the M82380 and the system. these pins are tied directly to the corre- sponding data bus pins of the i386 processor local bus. the data bus is also used for interrupt vectors generated by the M82380 in the interrupt acknowl- edge cycle. during slave i/o operations, the M82380 expects a single byte to be written or read. when the i386 host processor writes into the M82380, either d0 d7 or d8 d15 will be latched into the M82380, depending upon how the byte enable (be0 be3 ) signals are driven. the M82380 does not need to look at d16 d31 since the i386 processor duplicates 271070 8 figure 7. clk2 and M82380 internal clock 13
M82380 the single byte data on both halves of the bus. when the m80386 host processor reads from the M82380, the single byte data will be duplicated four times on the data bus; i.e., on d0 d7, d8 d15, d16 d23 and d24 d31. during master mode, the M82380 can transfer 32-, 16-, and 8-bit data between memory (or i/o devices) and i/o devices (or memory) via the data bus. 2.2.3 address bus (a31 a2) these three-state bidirectional signals are connect- ed directly to the i386 address bus. in the slave mode, they are used as input signals so that the processor can address the M82380 internal ports/ registers. in the master mode, they are used as out- put signals by the M82380 to address memory and peripheral devices. the address bus is capable of addressing 4 g-bytes of physical memory space (00000000h to ffffffffh), and 64 k-bytes of i/o addresses (00000000h to 0000ffffh). 2.2.4 byte enable (be3 be0 ) these bidirectional pins select specific byte(s) in the double word addressed by a31 a2. similar to the address bus function, these signals are used as in- puts to address internal M82380 registers during slave mode operation. during master mode opera- tion, they are used as outputs by the M82380 to ad- dress memory and i/o locations. in addition to the above function, be3 is used to enable a production test mode and must be low during reset. the i386 processor will automatically hold be3 low during reset. the definitions of the byte enable signals depend upon whether the M82380 is in the master or slave mode. these definitions are depicted in table 1. table 1. byte enable signals as inputs (slave mode): be3 be0 implied a1, a0 data bits written to M82380 * xxx0 00 d0 d7 xx01 01 d8 d15 x011 10 d0 d7 x111 11 d8 d15 x don't care * during read, data will be duplicated on d0 d7, d8 d15, d16 d23, and d24 d31. during write, the m80386 host processor duplicates data on d0 d15, and d16 d31, so that the M82380 is concerned only with the lower half of the data bus. as outputs (master mode): byte to be accessed logical byte presented on be3 be0 relative to a31 a2 data bus during write only * d2431 d1623 d815 d07 1110 0 u u u a 1101 1 u u a a 1011 2 u a u a 0111 3 a u a a 1001 1, 2 u b a a 1100 0, 1 u u b a 0011 2, 3 b a b a 1000 0, 1, 2 u c b a 0001 1, 2, 3 c b a a 0000 0, 1, 2, 3 d c b a u e undefined a e logical d0 d7 b e logical d8 d15 c e logical d16 d23 d e logical d24 d31 * actual number of bytes accessed depends upon the programmed data path width. 14
M82380 2.2.5 bus cycle definition signals (d/c , w/r , m/io ) these three-state bidirectional signals define the type of bus cycle being performed. w/r distin- guishes between write and read cycles. d/c distin- guishes between processor data and control cycles. m/io distinguishes between memory and i/o cy- cles. during slave mode, these signals are driven by the i386 host processor; during master mode, they are driven by the M82380. in either mode, these signals will be valid when the address status (ads ) is driven low. exact bus cycle definitions are given in table 2. note that some combinations are recognized as inputs, but not generated as outputs. in the master mode, d/c is always high. 2.2.6 address status (ads ) this bidirectional signal indicates that a valid ad- dress (a2 a31, be0 be3 ) and bus cycle definition (w/r , d/c , m/io ) is being driven on the bus. in the master mode, it is driven by the M82380 as an out- put. in the slave mode, this signal is monitored as an input by the M82380. by the current and past status of ads and the ready input, the M82380 is able to determine, during slave mode, if the next bus cycle is a pipelined address cycle. ads is asserted during t1 and t2p bus states (see bus state definition). note that during the idle states at the beginning and the end of a dma process, neither the i386 proces- sor nor the M82380 is driving the ads signal; i.e., the signal is left floated. therefore, it is important to use a pull-up resistor (approximately 10 k x )onthe ads signal. 2.2.7 transfer acknowledge (ready ) this input indicates that the current bus cycle is complete. in the master mode, assertion of this sig- nal indicates the end of a dma bus cycle. in the slave mode, the M82380 monitors this input and ads to detect a pipelined address cycles. this sig- nal should be tied directly to the ready input of the i386 host processor. 2.2.8 next address request (na ) this input is used to indicate to the M82380 in the master mode that the system is requesting address pipelining. when driven low by either memory or peripheral devices during master mode, it indicates that the system is prepared to accept a new address and bus cycle definition signals from the M82380 before the end of the current bus cycle. if this input is active when sampled by the M82380, the next ad- dress is driven onto the bus, provided a bus request is already pending internally. this input pin is monitored only in the master mode. in the slave mode, the M82380 uses the ads and ready signals to determine address pipelining cy- cles, and na will be ignored. 2.2.9 reset (reset, cpurst) reset this synchronous input suspends any operation in progress and places the M82380 in a known initial state. upon reset, the M82380 will be in the slave mode waiting to be initialized by the i386 host table 2. bus cycle definition m/io d/c w/r as inputs as outputs 0 0 0 interrupt not generated acknowledge 0 0 1 undefined not generated 0 1 0 i/o read i/o read 0 1 1 i/o write i/o write 1 0 0 undefined not generated 1 0 1 halt if not generated be (30) e x011 shutdown if be (30) e xxx0 1 1 0 memory read memory read 1 1 1 memory write memory write 15
M82380 table 3. output signals following reset signal level a2 a31, d0 d31, be0 be3 float d/c , w/r , m/io , ads float readyo `1' eop `1' (weak pull-up) edack2 edack0 `100' hold `0' int undefined * tout1/ref , tout2 /irq3 , tout3 undefined * cpurst `0' * the interrupt controller and programmable interval timer are initialized by software commands. processor. the M82380 is reset by asserting reset for 15 or more clk2 periods. when reset is as- serted, all other input pins are ignored, and all other bus pins are driven to an idle bus state as shown in table 3. the M82380 will determine the phase of its internal clock following reset going inactive. reset is level-sensitive and must be synchronous to the clk2 signal. therefore, this reset input should be tied to the reset output of the clock generator. the reset setup and hold time require- ments are shown in figure 8. cpurst this output signal is used to reset the i386 host processor. it will go active (high) whenever one of the following events occurs: a) M82380's reset in- put is active; b) a software reset command is is- sued to the M82380; or c) when the M82380 detects a processor shutdown cycle and when this detec- tion feature is enabled (see cpu reset and shut- down detect). when activated, cpurst will be held active for 62 clk2 periods. the timing of cpurst is such that the i386 processor will be in synchroniza- tion with the M82380. this timing is shown in figure 9. 271070 9 t30-reset hold time t31-reset setup time figure 8. reset timing 271070 10 t33-cpu reset from clk2 figure 9. cpurst timing 16
M82380 2.2.10 interrupt out (int) this output pin is used to signal the i386 host proc- essor that one or more interrupt requests (either in- ternal or external) are pending. the processor is ex- pected to respond with an interrupt acknowledge cycle. this signal should be connected directly to the maskable interrupt request (intr) input of the i386 host processor. 2.3 M82380 bus timing the M82380 internally divides the clk2 signal by two to generate its internal clock. figure 7 shows the relationship of clk2 and the internal clock. the in- ternal clock consists of two phases: phi1 and phi2. each clk2 period is a phase of the internal clock. in figure 7, both phi1 and phi2 of the M82380 internal clock are shown. in the M82380, whether it is in the master or slave mode, the shortest time unit of bus activity is a bus state. a bus state, which is also referred as a `t-state', is defined as one M82380 phi2 clock peri- od (i.e., two clk2 periods). recall in table 2, there are six different types of bus cycles in the M82380 as defined by the m/io , d/c and w/r signals. each of these bus cycles is composed of two or more bus states. the length of a bus cycle depends on when the ready input is asserted (i.e., driven low). 2.3.1 address pipelining the M82380 supports address pipelining as an op- tion in both the master and slave mode. this feature typically allows a memory or peripheral device to op- erate with one less wait state than would otherwise be required. this is possible because during a pipe- lined cycle, the address and bus cycle definition of the next cycle will be generated by the bus master while waiting for the end of the current cycle to be acknowledged. the pipelined bus is especially well suited for interleaved memory environment. for 16 mhz interleaved memory designs with 100 ns ac- cess time drams, zero wait state memory accesses can be achieved when pipelined addressing is se- lected. in the master mode, the M82380 is capable of initiat- ing, on a cycle-by-cycle basis, either a pipelined or non-pipelined access depending upon the state of the na input. if a pipelined cycle is requested (indi- cated by na being driven low), the M82380 will drive the address and bus cycle definition of the next cycle as soon as there is an internal bus request pending. in the slave mode, the M82380 is constantly moni- toring the ads and ready signals on the processor local bus to determine if the current bus cycle is a pipelined cycle. if a pipelined cycle is detected, the M82380 will request one less wait state from the processor if the wait state generator feature is se- lected. on the other hand, during an M82380 inter- nal register access in a pipelined cycle, it will make use of the advance address and bus cycle informa- tion. in all cases, address pipelining will result in a savings of one wait state. 2.3.2 master mode bus timing when the M82380 is in the master mode, it will be in one of six bus states. figure 10 shows the complete bus state diagram of the master mode, including pipelined address states. as seen in the figure, the M82380 state diagram is very similar to that of the i386 processor. the major difference is that in the M82380, there is no hold state. also, in the M82380, the conditions for some state transitions depend upon whether it is the end of a dma process. note: the term `end of a dma process' is loosely defined here. it depends on the dma modes of operation as well as the state of the eop and dreq inputs. this is explained in detail in section 3edma con- troller. 17
M82380 the M82380 will enter the idle state, ti, upon re- set and whenever the internal address is not avail- able at the end of a dma cycle or at the end of a dma process. when address pipelining is not used (na is not asserted), a new bus cycle always begins with state t1. during t1, address and bus cycle defi- nition signals will be driven on the bus. t1 is always followed by t2. if a bus cycle is not acknowledged (with ready ) during t2 and na is negated, t2 will be repeated. when the end of the bus cycle is acknowledged dur- ing t2, the following state will be t1 of the next bus cycle (if the internal address latch is loaded and if this is not the end of the dma process). otherwise, the ti state will be entered. therefore, if the memory or peripheral accessed is fast enough to respond within the first t2, the fastest non-pipelined cycle will take one t1 and one t2 state. use of the address pipelining feature allows the M82380 to enter three additional bus states: t1p, t2p, and t2i. t1p is the first bus state of a pipelined bus cycle. t2p follows t1p (or t2) if na is asserted when sampled. the M82380 will drive the bus with the address and bus cycle definition signals of the next cycle during t2p. from the state diagram, it can be seen that after an idle state ti, the first bus cycle must begin with t1, and is therefore a non-pipelined bus cycle. the next bus cycle can be pipelined if na is asserted and the previous bus cycle ended in a t2p state. once the M82380 is in a pipelined cycle and provided that na is asserted in subsequent cy- cles, the M82380 will be switching between t1p and t2p states. if the end of the current bus cycle is not acknowledged by the ready input, the M82380 will extend the cycle by adding t2p states. the fastest pipelined cycle will consist of one t1p and one t2p state. 271070 11 note: adaveinternal address available figure 10. master mode state diagram 18
M82380 the M82380 will enter state t2i when na is assert- ed and when one of the following two conditions occurs. the first condition is when the M82380 is in state t2. t2i will be entered if ready is not assert- ed and there is no next address available. this situa- tion is similar to a wait state. the M82380 will stay in t2i for as long as this condition exists. the second condition which will cause the M82380 enter t2i is when the M82380 is in state t1p. before going to state t2p, the M82380 needs to wait in state t2i until the next address is available. also, in both cas- es, if the dma process is complete, the M82380 will enter the t2i state in order to finish the current dma cycle. figure 11 is a timing diagram showing non-pipelined bus accesses in the master mode. figure 12 shows the timing of pipelined accesses in the master mode. 271070 12 figure 11. non-pipelined bus cycles 271070 13 figure 12. pipelined bus cycles 19
M82380 2.3.3 slave mode bus timing figure 13 shows the slave mode bus timing in both pipelined and non-pipelined cycles when the M82380 is being accessed. recall that during slave mode, the M82380 will constantly monitor the ads and ready signals to determine if the next cycle is pipelined. in figure 13, the first cycle is non-pipe- lined and the second cycle is pipelined. in the pipe- lined cycle, the M82380 will start decoding the ad- dress and bus cycle signals one bus state earlier than in a non-pipelined cycle. the ready input signal is sampled by the m80386 host processor to determine the completion of a bus cycle. this occurs during the end of every t2 and t2p state. normally, the output of the M82380 wait state generator, readyo , is directly connected to the ready input of the i386 host processor and the M82380. in such case, readyo and ready will be identical (see wait state generator). 271070 14 note: na is shown here only for timing reference. it is not sampled by the M82380 during slave mode. when the M82380 registers are accessed, it will take one or more wait states in pipelined and two or more wait states in non-pipelined cycle to complete the internal access. figure 13. slave read/write timing 20
M82380 3.0 dma controller the M82380 dma controller is capable of transfer- ring data between any combination of memory and/ or i/o, with any combination (8-, 16-, or 32-bits) of data path widths. bus bandwidth is optimized through the use of an internal temporary register which can disassemble or assemble data to or from either an aligned or a non-aligned destination or source. figure 14 is a block diagram of the M82380 dma controller. the M82380 has eight channels of dma. each channel operates independently of the others. with- in the operation of the individual channels, there are many different modes of data transfer available. many of the operating modes can be intermixed to provide a very versatile dma controller. 271070 15 figure 14. M82380 dma controller block diagram 21
M82380 3.1 functional description in describing the operation of the M82380's dma controller, close attention to terminology is required. before entering the discussion of the function of the M82380 dma controller, the following explanations of some of the terminology used herein may be of benefit. first, a few terms for clarification: dma processea dma process is the execution of a programmed dma task from beginning to end. each dma process requires initial programming by the host m80386 microprocessor. bufferea contiguous block of data. buffer transferethe action required by the dma to transfer an entire buffer. data transferethe dma action in which a group of bytes, words, or double words are moved between devices by the dma controller. a data transfer operation may involve movement of one or many bytes. bus cycleeaccess by the dma to a single byte, word, or double word. each dma channel consists of three major compo- nents. these components are identified by the con- tents of programmable registers which define the memory or i/o devices being serviced by the dma. they are the target, the requester, and the byte count. they will be defined generically here and in greater detail in the dma register definition section. the requester is the device which requires service by the M82380 dma controller, and makes the re- quest for service. all of the control signals which the dma monitors or generates for specific channels are logically related to the requester. only the re- quester is considered capable of initiating or termi- nating a dma process. the target is the device with which the requester wishes to communicate. as far as the dma process is concerned, the target is a slave which is incapa- ble of control over the process. the direction of data transfer can be either from re- quester to target or from target to requester; i.e., each can be either a source or a destination. the requester and target may each be either i/o or memory. each has an address associated with it that can be incremented, decremented, or held con- stant. the addresses are stored in the requester address registers and target address registers, respectively. these registers have two parts: one which contains the current address being used in the dma process (current address register), and one which holds the programmed base address (base address register). the contents of the base regis- ters are never changed by the M82380 dma con- troller. the current registers are incremented or decremented according to the progress of the dma process. the byte count is the component of the dma pro- cess which dictates the amount of data which must be transferred. current and base byte count regis- ters are provided. the current byte count register is decremented once for each byte transferred by the dma process. when the register is decremented past zero, the byte count is considered `expired' and the process is terminated or restarted, depend- ing on the mode of operation of the channel. the point at which the byte count expires is called `ter- minal count' and several status signals are depen- dent on this event. each channel of the M82380 dma controller also contains a 32-bit temporary register for use in as- sembling and disassembling non-aligned data. the operation of this register is transparent to the user, although the contents of it may affect the timing of some dma handshake sequences. since there is data storage available for each channel, the dma controller can be interrupted without loss of data. the M82380 dma controller is a slave on the bus until a request for dma service is received via either a software request command or a hardware request signal. the host processor may access any of the control/status or channel registers at any time the M82380 is a bus slave. figure 15 shows the flow of operations that the dma controller performs. at the time a dma service request is received, the dma controller issues a bus hold request to the host processor. the M82380 becomes the bus mas- ter when the host relinquishes the bus by asserting a hold acknowledge signal. the channel to be serv- iced will be the one with the highest priority at the time the dma controller becomes the bus master. the dma controller will remain in control of the bus until the hold acknowledge signal is removed, or un- til the current dma transfer is complete. while the M82380 dma controller has control of the bus, it will perform the required data transfer(s). the type of transfer, source and destination addresses, and amount of data to transfer are programmed in the control registers of the dma channel which re- ceived the request for service. 22
M82380 271070 16 figure 15. flow of dma controller operation at completion of the dma process, the M82380 will remove the bus hold request. at this time the M82380 becomes a slave again, and the host re- turns to being a master. if there are other dma channels with requests pending, the controller will again assert the hold request signal and restart the bus arbitration and switching process. 3.2 interface signals there are fourteen control signals dedicated to the dma process. they include eight dma channel re- quests (dreqn), three encoded dma acknowledge signals (edackn), processor hold and hold ac- knowledge (hold, hlda), and end-of-process (eop ). the dreqn inputs and edack(0 2) outputs are handshake signals to the devices requiring dma service. the hold output and hlda input are hand- shake signals to the host processor. figure 16 shows these signals and how they interconnect be- tween the M82380 dma controller, and the re- quester and target devices. 271070 17 figure 16. requester, target, and dma controller interconnection 23
M82380 3.2.1 dreqn and edack(0 2) these signals are the handshake signals between the peripheral and the M82380. when the peripheral requires dma service, it asserts the dreqn signal of the channel which is programmed to perform the service. the M82380 arbitrates the dreqn against other pending requests and begins the dma pro- cess after finishing other higher priority processes. when the dma service for the requested channel is in progress, the edack(0 2) signals represent the dma channel which is accessing the requester. the 3-bit code on the edack(0 2) lines indicates the number of the channel presently being serviced. table 4 shows the encoding of these signals. note that channel 4 does not have a corresponding hard- ware acknowledge. the dma acknowledge (edack) signals indicate the active channel only during dma accesses to the requester. during accesses to the target, edack(0 2) has the idle code (100). edack(0 2) can thus be used to select a requester device dur- ing a transfer. table 4. edack encoding during a dma transfer edack2 edack1 edack0 active channel 000 0 001 1 010 2 011 3 1 0 0 target access 101 5 110 6 111 7 dreqn can be programmed as either an asynchro- nous or synchronous input. the edackn signals are always active. they either indicate `no acknowledge' or they indicate a bus ac- cess to the requester. the acknowledge code is ei- ther 100, for an idle dma or during a dma access to the target, or `n' during a requester access, where n is the binary value representing the channel. a simple 3-line to 8-line decoder can be used to pro- vide discrete acknowledge signals for the peripher- als. 3.2.2 hold and hlda the hold request (hold) and hold acknowledge (hlda) signals are the handshake signals between the dma controller and the host processor. hold is an output from the M82380 and hlda is an input. hold is asserted by the dma controller when there is a pending dma request, thus requesting the proc- essor to give up control of the bus so the dma pro- cess can take place. the m80386 responds by as- serting hlda when it is ready to relinquish control of the bus. the M82380 will begin operations on the bus one clock cycle after the hlda signal goes active. for this reason, other devices on the bus should be in the slave mode when hlda is active. hold and hlda should not be used to gate or se- lect peripherals requesting dma service. this is be- cause of the use of dma-like operations by the dram refresh controller. the refresh controller is arbitrated with the dma controller for control of the bus, and refresh cycles have the highest priority. a refresh cycle will take place between dma cycles without relinquishing bus control. see the arbitration of refresh requests for a more detailed discussion of the interaction between the dma controller and the dram refresh controller. 3.2.3 eop eop is a bidirectional signal used to indicate the end of a dma process. the M82380 activates this as an output during the t2 states of the last requester bus cycle for which a channel is programmed to execute. the requester should respond by either withdraw- ing its dma request, or interrupting the host proces- sor to indicate that the channel needs to be pro- grammed with a new buffer. as an input, this signal is used to tell the dma controller that the peripheral being serviced does not require any more data to be transferred. this indicates that the current buffer is to be terminated. eop can be programmed as either an asynchro- nous or a synchronous input. details on synchro- nous versus asynchronous operation of this pin are described later in this data sheet. 3.3 modes of operation the M82380 dma controller has many independent operating functions. when designing peripheral in- terfaces for the M82380 dma controller, all of the functions or modes must be considered. all of the channels are independent of each other (except in priority of operation) and can operate in any of the modes. many of the operating modes, though inde- pendently programmable, affect the operation of other modes. because of the large number of com- 24
M82380 binations possible, each programmable mode is dis- cussed here with its affects on the operation of other modes. the entire list of possible combinations will not be presented. table 5 shows the categories of dma features avail- able in the M82380. each of the five major categories is independent of the others. the sub- categories are the available modes within the major function or mode category. the following sections explain each mode or function and its relation to oth- er features. table 5. dma operating modes i. target/requester definition a. data transfer direction b. device type c. increment/decrement/hold ii. buffer processes a. single buffer process b. buffer auto-initialize process c. buffer chaining process iii. data transfer/handshake modes a. single transfer mode b. demand transfer mode c. block transfer mode d. cascade mode iv. priority arbitration a. fixed b. rotating c. programmable fixed v. bus operation a. fly-by (single-cycle)/two-cycle b. data path width c. read, write, or verify cycles 3.3.1 target/requester definition all dma transfers involve three devices: the dma controller, the requester, and the target. since the devices to be accessed by the dma controller vary widely, the operating characteristics of the dma controller must be tailored to the requester and target devices. the requester can be defined as either the source or the destination of the data to be transferred. this is done by specifying a write or a read transfer, respectively. in a read transfer, the target is the data source and the requester is the destination for the data. in a write transfer, the requester is the source and the target in the destination. the requester and target addresses can each be independently programmed to be incremented, dec- remented, or held constant. as an example, the M82380 is capable of reversing a string or data by having a requester address increment and the tar- get address decrement in a memory-to-memory transfer. 3.3.2 buffer transfer processes the M82380 dma controller allows three program- mable buffer transfer processes. these processes define the logical way in which a buffer of data is accessed by the dma. the three buffer transfer processes include the sin- gle buffer process, the buffer auto-initialize pro- cess, and the buffer chaining process. these pro- cesses require special programming considerations. see the dma programming section for more details on setting up the buffer transfer processes. single buffer process the single buffer process allows the dma channel to transfer only one buffer of data. when the buffer has been completely transferred (current byte count decremented past zero or eop input active), the dma process ends and the channel becomes idle. in order for that channel to be used again, it must be reprogrammed. the single buffer process is usually used when the amount of data to be transferred is known exactly, and it is also known that there is not likely to be any data to follow before the operating system can reprogram the channel. buffer auto-initialize process the buffer auto-initialize process allows multiple groups of data to be transferred to or from a single buffer. this process does not require reprogram- ming. the current registers are automatically repro- grammed from the base registers when the current process is terminated, either by an expired byte count or by an external eop signal. the data trans- ferred will always be between the same target and requester. the auto-initialization/process-execution cycle is re- peated, with a hold/hlda re-arbitration, until the channel is either disabled or re-programmed. 25
M82380 buffer chaining process the buffer chaining process is useful for transfer- ring large quantities of data into non-contiguous buffer areas. in this process, a single channel is used to process data from several buffers, while having to program the channel only once. each new buffer is programmed in a pipelined operation that provides the new buffer information while the old buffer is being processed. the chain is created by loading new buffer information while the M82380 dma controller is processing the current buffer. when the current buffer expires, the M82380 dma controller automatically restarts the channel using the new buffer information. loading the new buffer information is done by an interrupt routine which is requested by the M82380. interrupt request 1 (irq1) is tied internally to the M82380 dma controller for this purpose. irq1 is generated by the M82380 when the new buffer infor- mation is loaded into the channel's current regis- ters, leaving the base registers `empty'. the inter- rupt service routine loads new buffer information into the base registers. the host processor is required to load the information for another buffer before the current byte count expires. the process repeats un- til the host programs the channel back to single buff- er operation, or until the channel runs out of buffers. the channel runs out of buffers when the current buffer expires and the base registers have not yet been loaded with new buffer information. when this occurs, the channel must be reprogrammed. if an external eop is encountered while executing a buffer chaining process, the current buffer is con- sidered expired and the new buffer information is loaded into the current registers. if the base regis- ters are `empty', the chain is terminated. the channel uses the base target address register as an indicator of whether or not the base registers are full. when the most significant byte of the base target register is loaded, the channel considers all of the base registers loaded, and removes the in- terrupt request. this requires that the other base registers (base requester address, last byte count) must be loaded before the base target ad- dress register. the reason for implementing the re- loading process this way is that, for most applica- tions, the byte count and the requester will not change from one buffer to the next, and therefore do not need to be reprogrammed. the details of pro- gramming the channel for the buffer chaining pro- cess can be found in the section of dma program- ming. 3.3.3 data transfer modes three data transfer modes are available in the M82380 dma controller. they are the single trans- fer, block transfer, and demand transfer modes. these transfer modes can be used in conjunction with any one of three buffer transfer modes: single buffer, auto-initialized buffer, and buffer chaining. any data transfer modes can be used under any of the buffer transfer modes. these modes are inde- pendently available for all dma channels. different devices being serviced by the dma con- troller require different handshaking sequences for data transfers to take place. three handshaking modes are available on the M82380, giving the de- signer the opportunity to use the dma controller as efficiently as possible. the speed at which data can be presented or read by a device can affect the way a dma controller uses the host's bus, thereby affect- ing not only data throughput during the dma pro- cess, but also affecting the host's performance by limiting its access to the bus. single transfer mode in the single transfer mode, one data transfer to or from the requester is performed by the dma con- troller at a time. the dreqn input is arbitrated and the hold/hlda sequence is executed for each transfer. transfers continue in this manner until the byte count expires, or until eop is sampled active. if the dreqn input is held active continuously, the en- tire dreq-hold-hlda-dack sequence is repeat- ed over and over until the programmed number of bytes has been transferred. bus control is released to the host between each transfer. figure 17 shows the logical flow of events which make up a buffer transfer using the single transfer mode. 26
M82380 271070 18 figure 17. buffer transfer in single transfer mode the single transfer mode is used for devices which require complete handshake cycles with each data access. data is transferred to or from the requester only when the requester is ready to perform the transfer. each transfer requires the entire dreq- hold-hlda-dack handshake cycle. figure 18 shows the timing of the single transfer mode cy- cles. block transfer mode in the block transfer mode, the dma process is ini- tiated by a dma request and continues until the byte count expires, or until eop is activated by the re- quester. the dreqn signal need only be held active until the first requester access. only a refresh cycle will interrupt the block transfer process. figure 19 illustrates the operation of the dma during the block transfer mode. figure 20 shows the tim- ing of the handshake signals during block mode transfers. 271070 19 figure 18. dma single transfer mode 27
M82380 271070 20 figure 19. buffer transfer in block transfer mode demand transfer mode the demand transfer mode provides the most flex- ible handshaking procedures during the dma pro- cess. a demand transfer is initiated by a dma re- quest. the process continues until the byte count expires, or an external eop is encountered. if the device being serviced (requester) desires, it can in- terrupt the dma process by de-activating the dreqn line. action is taken on the condition of dreqn during requester accesses only. the ac- cess during which dreqn is sampled inactive is the last requester access which will be performed dur- ing the current transfer. figure 21 shows the flow of events during the transfer of a buffer in the demand mode. 271070 21 figure 20. block mode transfers 28
M82380 271070 22 figure 21. buffer transfer in demand transfer mode when the dreqn line goes inactive, the dma con- troller will complete the current transfer, including any necessary accesses to the target, and relin- quish control of the bus to the host. the current pro- cess information is saved (byte count, requester and target addresses, and temporary register). the requester can restart the transfer process by reasserting dreqn. the M82380 will arbitrate the request with other pending requests and begin the process where it left off. figure 22 shows the timing of handshake signals during demand transfer mode operation. using the demand transfer mode allows peripherals to access memory in small, irregular bursts without wasting bus control time. the M82380 is designed to give the best possible bus control latency in the de- mand transfer mode. bus control latency is defined here as the time from the last active bus cycle of the previous bus master to the first active bus cycle of the new bus master. the M82380 dma controller will perform its first bus access cycle two bus states after hlda goes active. in the typical configuration, bus control is returned to the host one bus state after the dreqn goes inactive. there are two cases where there may be more than one bus state of bus control latency at the end of a transfer. the first is at the end of an auto-initialize process, and the second is at the end of a process where the source is the requester and two-cycle transfers are used. when a buffer auto-initialize process is complete, the M82380 requires seven bus states to reload the 271070 23 figure 22. demand mode transfers 29
M82380 current registers from the base registers of the auto-initialized channel. the reloading is done while the M82380 is still the bus master so that it is pre- pared to service the channel immediately after relin- quishing the bus, if necessary. in the case where the requester is the source, and two-cycle transfers are being used, there are two extra idle states at the end of the transfer process. this occurs due to housekeeping in the dma's inter- nal pipeline. these two idle states are present only after the very last requester access, before the dma controller de-activates the hold signal. 3.3.4 channel priority arbitration dma channel priority can be programmed into one of two arbitration methods: fixed or rotating. the four lower dma channels and the four upper dma channels operate as if they were two separate dma controllers operating in cascade. the lower group of four channels (0 3) is always prioritized between channels 7 and 4 of the upper group of channels (4 7). figure 23 shows a pictorial representation of the priority grouping. the priority can thus be set up as rotating for one group of channels and fixed for the other, or any other combination. while in fixed priority, the pro- grammer can also specify which channel has the lowest priority. 271070 24 figure 23. dma priority grouping the M82380 dma controller defaults to fixed priori- ty. channel 0 has the highest priority, then 1, 2, 3, 4, 5, 6, 7. channel 7 has the lowest priority. any time the dma controller arbitrates dma requests, the re- questing channel with the highest priority will be serviced next. fixed priority can be entered into at any time by a software command. the priority levels in effect after the mode switch are determined by the current setting of the programmable priority. programmable priority is available for fixing the prior- ity of the dma channels within a group to levels oth- er than the default. through a software command, the channel to have the lowest priority in a group can be specified. each of the two groups of four channels can have the priority fixed in this way. the other channels in the group will follow the natural fixed priority sequence. this mode affects only the priority levels while operating with fixed priority. for example, if channel 2 is programmed to have the lowest priority in its group, channel 3 has the highest priority. in descending order, the other channels would have the following priority: (3, 0, 1, 2), 4, 5, 6, 7 (channel 2 lowest, channel 3 highest). if the upper group were programmed to have channel 5 as the lowest priority channel, the priority would be (again, highest to lowest): 6, 7, (3, 0, 1, 2), 4, 5. figure 24 shows this example pictorially. the lower group is always prioritized as a fifth channel of the upper group (between channels 4 and 7). high priority low priority 271070 25 figure 24. example of programmed priority the dma controller will only accept programmable priority commands while the addressed group is op- erating in fixed priority. switching from fixed to ro- tating priority preserves the current priority levels. switching from rotating to fixed priority returns the priority levels to those which were last programmed by use of programmable priority. rotating priority allows the devices using dma to share the system bus more evenly. an individual channel does not retain highest priority after being serviced, priority is passed to the next highest priori- ty channel in the group. the channel which was most recently serviced inherits the lowest priority. this rotation occurs each time a channel is serviced. figure 25 shows the sequence of events as priority is passed between channels. note that the lower group rotates within the upper group, and that serv- icing a channel within the lower group causes rota- tion within the group as well as rotation of the upper group. 30
M82380 0123 4567 edefault (highest to lowest) dreq2 and dreq6eprocess channel 2 4567 3012 echannel 2 drops to lowest priority within group. lower group drops to lowest priority within upper group. 2(double rotation) dreq6 (still) and dreq7eprocess channel 6 7 3 0 1 2 4 5 6 echannel 6 drops to lowest priority within group dreq7 (still) and dreq0eprocess channel 7 3012 4567 echannel 7 drops to lowest priority within group dreq0 (still) and dreq1eprocess channel 0 4567 1230 echannel 0 drops to lowest priority within group (double rotation) dreq1 (still)eprocess channel 1 4567 2301 echannel 1 drops to lowest priority within group figure 25. rotating channel priority. lower and upper groups are programmed for the rotating priority mode. 31
M82380 3.3.5 combining priority modes since the dma controller operates as two four- channel controllers in cascade, the overall priority scheme of all eight channels can take on a variety of forms. there are four possible combinations of prior- ity modes between the two groups of channels: fixed priority only (default), fixed priority upper group/rotating priority lower group, rotating priority upper group/fixed priority lower group, and rotating priority only. figure 26 illustrates the operation of the two combined priority methods. high low 0 1 2 3 4 5 6 7 edefault priority high low 4 5 6 7 0 1 2 3 after servicing channel 2 high low 7 0 1 2 3 4 5 6 eafter servicing channel 6 high low 4 5 6 7 0 1 2 3 eafter servicing channel 1 case 1 0 3 fixed priority, 4 7 rotating priority high low 0 1 2 3 4 5 6 7 default priority high low 3 0 1 2 4 5 6 7 after servicing channel 2 high low 3 0 1 2 4 5 6 7 after servicing channel 6 high low 2 3 0 1 4 5 6 7 after servicing channel 1 case 2 0 3 rotating priority, 4 7 fixed priority figure 26. combining priority modes 32
M82380 3.3.6 bus operation data may be transferred by the dma controller us- ing two different bus cycle operations: fly-by (one- cycle) and two-cycle. these bus handshake meth- ods are selectable independently for each channel through a command register. device data path widths are independently programmable for both target and requester. also selectable through soft- ware is the direction of data transfer. all of these parameters affect the operation of the M82380 on a bus-cycle by bus-cycle basis. fly-by transfers the fly-by transfer mode is the fastest and most efficient way to use the M82380 dma controller to transfer data. in this method of transfer, the data is written to the destination device at the same time it is read from the source. only one bus cycle is used to accomplish the transfer. in the fly-by mode, the dma acknowledge signal is used to select the requester. the dma controller simultaneously places the address of the target on the address bus. the state of m/io and w/r during the fly-by transfer cycle indicate the type of target and whether the target is being written to or read from. the target's bus size is used as an incremen- ter for the byte count. the requester address regis- ters are ignored during fly-by transfers. note that memory-to-memory transfers cannot be done using the fly-by mode. only one memory or i/o address is generated by the dma controller at a time during fly-by transfers. only one of the devices being accessed can be selected by an address. also, the fly-by method of data transfer limits the hardware to accesses of devices with the same data bus width. the temporary registers are not affect- ed in the fly-by mode. fly-by transfers also require that the data paths of the target and requester be directly connected. this requires that successive fly-by accesses be to doubleword boundaries, or that the requester be capable of switching its connections to the data bus. two-cycle transfers two-cycle transfers can also be performed by the M82380 dma controller. these transfers require at least two bus cycles to execute. the data being transferred is read into the dma controller's tempo- rary register during the first bus cycle(s). the sec- ond bus cycle is used to write the data from the temporary register to the destination. if the addresses of the data being transferred are not word or doubleword aligned, the M82380 will recognize the situation and read and write the data in groups of bytes, placing them always at the proper destination. this process of collecting the desired bytes and putting them together is called `byte as- sembly'. the reverse process (reading from aligned locations and writing to non-aligned locations) is called `byte disassembly'. the assembly/disassembly process takes place transparent to the software, but can only be done while using the two-cycle transfer method. the M82380 will always perform the assembly/disas- sembly process as necessary for the current data transfer. any data path widths for either the re- quester or target can be used in the two-cycle mode. this is very convenient for interfacing existing 8- and 16-bit peripherals to the i386 processor's 32-bit bus. the M82380 dma controller always attempts to fill the temporary register from the source before writ- ing any data to the destination. if the process is ter- minated before the temporary register is filled (tc or eop ), the M82380 will write the partial data to the destination. if a process is temporarily suspended (such as when dreqn is de-activated during a de- mand transfer), the contents of a partially filled tem- porary register will be stored within the M82380 un- til the process is restarted. for example, if the source is specified as an 8-bit device and the destination as a 32-bit device, there will be four reads as necessary from the 8-bit source to fill the temporary register. then the M82380 will write the 32-bit contents to the destination. this cy- cle will repeat until the process is terminated or sus- pended. note that for a single-cycle transfer mode of opera- tion, the internal circuitry of the dma controller actu- ally executes single transfers by removing the dreq from the internal arbitration. thus single transfers from an 8-bit requester to a 32-bit target will consist of four complete and independent 8-bit requester cy- cles, between which bus control is released and re- requested. finally, the 32-bit data will be transferred to the target device from the temporary register be- fore the fifth requester cycle. with two-cycle transfers, the devices that the M82380 accesses can reside at any address within i/o or memory space. the device must be able to decode the byte-enables (ben ). also, if the device cannot accept data in byte quantities, the program- mer must take care not to allow the dma controller to access the device on any address other than the device boundary. 33
M82380 data path width and data transfer rate considerations the number of bus cycles used to transfer a single `word' of data is affected by whether the two-cycle or the fly-by (single-cycle) transfer method is used. the number of bus cycles used to transfer data di- rectly affects the data transfer rate. inefficient use of bus cycles will decrease the effective data transfer rate that can be obtained. generally, the data trans- fer rate is halved by using two-cycle transfers in- stead of fly-by transfers. the choice of data path widths of both target and requester affects the data transfer rate also. during each bus cycle, the largest pieces of data possible should be transferred. the data path width of the devices to be accessed must be programmed into the dma controller. the M82380 defaults after reset to 8-bit-to-8-bit data transfers, but the target and requester can have different data path widths, independent of each oth- er and independent of the other channels. since this is a software programmable function, more discus- sion of the uses of this feature are found in the sec- tion on programming. read, write, and verify cycles three different bus cycle types may be used in a data transfer. they are the read, write, and verify cycles. these cycle types dictate the way in which the M82380 operates on the data to be transferred. a read cycle transfers data from the target to the requester. a write cycle transfers data from the requester to the target. in a fly-by transfer, the ad- dress and bus status signals indicate the access (read or write) to the target; the access to the re- quester is assumed to be the opposite. the verify cycle is used to perform a data read only. no write access is indicated or assumed in a verify cycle. the verify cycle is useful for validating block fill operations. an external comparator must be pro- vided to do any comparisons on the data read. 3.4 bus arbitration and handshaking figure 27 shows the flow of events in the dma re- quest arbitration process. the arbitration sequence starts when the requester asserts a dreqn (or dma service is requested by software). figure 28 shows the timing of the sequence of events follow- ing a dma request. this sequence is executed for each channel that is activated. the dreqn signal can be replaced by a software dma channel request with no change in the sequence. 271070 26 figure 27. bus arbitration and dma sequence after the requester asserts the service request, the M82380 will request control of the bus via the hold signal. the M82380 will always assert the hold sig- nal one bus state after the service request is assert- ed. the i386 processor responds by asserting the hlda signal, thus releasing control of the bus to the M82380 dma controller. priority of pending dma service requests is arbitrat- ed during the first state after hlda is asserted by the i386 processor. the next state will be the begin- ning of the first transfer access of the highest priority process. 34
M82380 when the M82380 dma controller is finished with its current bus activity, it returns control of the bus to the host processor. this is done by driving the hold signal inactive. the M82380 does not drive any address or data bus signals after hold goes low. it enters the slave mode until another dma pro- cess is requested. the processor acknowledges that it has regained control of the bus by forcing the hlda signal inactive. note that the M82380's dma controller will not re-request control of the bus until the entire hold/hlda handshake sequence is complete. the M82380 dma controller will terminate a current dma process for one of three reasons: expired byte count, end-of-process command (eop activated) from a peripheral, or de-activated dma request sig- nal. in each case, the controller will de-assert hold immediately after completing the data transfer in progress. these three methods of process termina- tion are illustrated in figures 29, 32, and 31, respec- tively. an expired byte count indicates that the current pro- cess is complete as programmed and the channel has no further transfers to process. the channel must be restarted according to the currently pro- grammed buffer transfer mode, or reprogrammed completely, including a new buffer transfer mode. if the peripheral activates the eop signal, it is indi- cating that it will not accept or deliver any more data for the current buffer. the M82380 dma controller considers this as a completion of the channel's cur- rent process and interprets the condition the same way as if the byte count expired. the action taken by the M82380 dma controller in response to a de-activated dreqn signal depends on the data transfer mode of the channel. in the demand mode, data transfers will take place as long as the dreqn is active and the byte count has not expired. in the block mode, the controller will com- plete the entire block transfer without relinquishing 271070 27 note: channel priority resolution takes place during the bus state before hlda is asserted, allowing the dma controller to respond to hlda without extra idle bus states. figure 28. beginning of a dma process 35
M82380 the bus, even if dreqn goes inactive before the transfer is complete. in the single mode, the control- ler will execute single data transfers, relinquishing the bus between each transfer, as long as dreqn is active. normal termination of a dma process due to expira- tion of the byte count (terminal count-tc) is shown in figure 29. the condition of dreqn is ignored until after the process is terminated. if the channel is pro- grammed to auto-initialize, hold will be held active for an additional seven clock cycles while the auto- initialization takes place. table 6 shows the dma channel activity due to eop or byte count expiring (terminal count). table 6. dma channel activity due to terminal count or external eop single auto- chaining- buffer process: or chaining- initialize base loaded base empty event terminal count true x true x true x eop input x 0 x 0 x 0 results current registers e e load load load load channel mask set set eeee eop output 0 x 0 x 1 x terminal count status set set set set e e software request clr clr clr clr e e 271070 28 figure 29. termination of a dma process due to expiration of current byte count 36
M82380 the M82380 always relinquishes control of the bus between channel services. this allows the hardware designer the flexibility to externally arbitrate bus hold requests, if desired. if another dma request is pend- ing when a higher priority channel service is com- pleted, the M82380 will relinquish the bus until the hold acknowledge is inactive. one bus state after the hlda signal goes inactive, the M82380 will as- sert hold again. this is illustrated in figure 30. 3.4.1 synchronous and asynchronous sampling of dreqn and eop as an indicator that a dma service is to be started, dreqn is always sampled asynchronously. it is sampled at the beginning of a bus state and acted upon at the end of the state. figure 28 illustrates the start of a dma process due to a dreqn input. the dreqn and eop inputs can be programmed to be sampled either synchronously or asynchronously to signal the end of a transfer. the synchronous mode affords the requester one bus state of extra time to react to an access. this means the requester can terminate a process on the current access, without losing any data. the asynchronous mode requires that the input signal be presented prior to the beginning of the last state of the requester access. the timing relationships of the dreqn and eop sig- nals to the termination of a dma transfer are shown in figures 31 and 32. figure 31 shows the termina- tion of a dma transfer due to inactive dreqn. fig- ure 32 shows the termination of a dma process due to an active eop input. in the synchronous mode, dreqn and eop are sampled at the end of the last state of every re- quester data transfer cycle. if eop is active or dreqn is inactive at this time, the M82380 recog- nizes this access to the requester as the last trans- fer. at this point, the M82380 completes the transfer in progress, if necessary, and returns bus control to the host. in the asynchronous mode, the inputs are sampled at the beginning of every state of a requester ac- cess. the M82380 waits until the end of the state to act on the input. dreqn and eop are sampled at the latest possible time when the M82380 can determine if another transfer is required. in the synchronous mode, dreqn and eop are sampled on the trailing edge of the last bus state before another data access cycle begins. the asynchronous mode requires that the signals be valid one clock cycle earlier. 271070 29 figure 30. switching between active dma channels 37
M82380 271070 30 figure 31. termination of a dma process due to de-asserting dreqn 271070 31 figure 32. termination of a dma process due to an external eop 38
M82380 while in the pipeline mode, if the na signal is sam- pled active during a transfer, the end of the state where na was sampled active is when the M82380 decides whether to commit to another transfer. the device must de-assert dreqn or assert eop before na is asserted, otherwise the M82380 will commit to another, possibly undesired, transfer. synchronous dreqn and eop sampling allows the peripheral to prevent the next transfer from occur- ring by de-activating dreqn or asserting eop dur- ing the current requester access, before the M82380 dma controller commits itself to another transfer. the dma controller will not perform the next transfer if it has not already begun the bus cy- cle. asynchronous sampling allows less stringent timing requirements than the synchronous mode, but requires that the dreqn signal be valid at the beginning of the next to last bus state of the current requester access. using the asynchronous mode with zero wait states can be very difficult. since the addresses and con- trol signals are driven by the M82380 near half-way through the first bus state of a transfer, and the asynchronous mode requires that dreqn be active before the end of the state, the peripheral being ac- cessed is required to present dreqn only a few nanoseconds after the control information is avail- able. this means that the peripheral's control logic must be extremely fast (practically non-causal). an alternative is the synchronous mode. 3.4.2 arbitration of cascaded master requests the cascade mode allows another dma-type de- vice to share the bus by arbitrating its bus accesses with the M82380's. seven of the eight dma chan- nels (0 3 and 5 7) can be connected to a cascaded device. the cascaded device requests bus control through the dreqn line of the channel which is pro- grammed to operate in cascade mode. bus hold ac- knowledge is signaled to the cascaded device through the edack lines. when the edack lines are active with the code for the requested cascade channel, the bus is available to the cascaded master device. 271070 32 figure 33. cascaded bus master 39
M82380 a cascade cycle begins the same way a regular dma cycle begins. the requesting bus master as- serts the dreqn line on the M82380. this bus con- trol request arbitrated as any other dma request would be. if any channel receives a dma request, the M82380 requests control of the bus. when the host acknowledges that it has released bus control, the M82380 acknowledges to the requesting master that it may access the bus. the M82380 enters an idle state until the new master relinquishes control. a cascade cycle will be terminated by one of two events: dreqn going inactive, or hlda going inac- tive. the normal way to terminate the cascade cycle is for the cascaded master to drop the dreqn sig- nal. figure 34 shows the two cascade cycle termina- tion sequences. the refresh controller may interrupt the cascaded master to perform a refresh cycle. if this occurs, the M82380 dma controller will de-assert the edack signal (hold acknowledge to cascaded master) and wait for the cascaded master to remove its hold re- quest. when the M82380 regains bus control, it will perform the refresh cycle in its normal fashion. after the refresh cycle has been completed, and if the cascaded device has re-asserted its request, the M82380 will return control to the cascaded master which was interrupted. 271070 33 cascade cycle termination by dreqn inactive 271070 34 cascade cycle termination by hlda inactive figure 34. cascade cycle termination 40
M82380 the M82380 assumes that it is the only device moni- toring the hlda signal. if the system designer wishes to place other devices on the bus as bus masters, the hlda from the processor must be in- tercepted before presenting it to the M82380. using the cascade capability of the M82380 dma control- ler offers a much better solution. 3.4.3 arbitration of refresh requests the arbitration of refresh requests by the dram re- fresh controller is slightly different from normal dma channel request arbitration. the M82380 dram re- fresh controller always has the highest priority of any dma process. it also can interrupt a process in progress. two types of processes in progress may be encountered: normal dma, and bus master cas- cade. in the event of a refresh request during a normal dma process, the dma controller will complete the data transfer in progress and then execute the re- fresh cycle before continuing with the current dma process. the priority of the interrupted process is not lost. if the data transfer cycle interrupted by the refresh controller is the last of a dma process, the refresh cycle will always be executed before control of the bus is transferred back to the host. when the refresh controller request occurs during a cascade cycle, the refresh controller must be as- sured that the cascaded master device has relin- quished control of the bus before it can execute the refresh cycle. to do this, the dma controller drops the edack signal to the cascaded master and waits for the corresponding dreqn input to go inactive. by dropping the dreqn signal, the cascaded mas- ter relinquishes the bus. the refresh controller then performs the refresh cycle. control of the bus is re- turned to the cascaded master if dreqn returns to an active state before the end of the refresh cycle, otherwise control is passed to the processor and the cascaded master loses its priority. 3.5 dma controller register overview the M82380 dma controller contains 44 registers which are accessable to the host processor. twen- ty-four of these registers contain the device ad- dresses and data counts for the individual dma channels (three per channel). the remaining regis- ters are control and status registers for initiating and monitoring the operation of the M82380 dma con- troller. table 7 lists the dma controller's registers and their accessability. table 7. dma controller registers register name access control/status registereone each per group command register i write only command register ii write only mode register i write only mode register ii write only software request register read/write mask set-reset register write only mask read-write register read/write status register read only bus size register write only chaining register read/write channel registerseone each per channel base target address write only current target address read only base requester address write only current requester address read only base byte count write only current byte count read only 3.5.1 control/status registers the following registers are available to the host processor for programming the M82380 dma con- troller into its various modes and for checking the operating status of the dma processes. each set of four dma channels has one of each of these regis- ters associated with it. command register i enables or disables the dma channels as a group. sets the priority mode (fixed or rotating) of the group. this write-only register is cleared by a hard- ware reset, defaulting to all channels enabled and fixed priority mode. command register ii sets the sampling mode of the dreqn and eop inputs. also sets the lowest priority channel for the group in the fixed priority mode. the functions pro- grammed through command register ii default after a hardware reset to: asynchronous dreqn and eop , and channels 3 and 7 lowest priority. mode register i mode register i programs the following functions for an individually selected channel: 41
M82380 type of transfereread, write, verify autoeinitializeeenable or disable target address counteincrement or decrement data transfer modeedemand, single, block, cascade mode register i functions default to the following after reset: verify transfer, auto-initialize disabled, in- crement target address, demand mode. mode register ii programs the following functions for an individually selected channel: target address holdeenable or disable requester address counteincrement or decrement requester address holdeenable or disable target device typeei/o or memory requester device typeei/o or memory transfer cyclesetwo-cycle or fly-by mode register ii functions are defined as follows after a hardware reset: disable target address hold, increment requester address, target (and re- quester) in memory, fly-by transfer cycles. note: requester device type ignored in fly-by transfers. software request register the dma controller can respond to service requests which are initiated by software. each channel has an internal request status bit associated with it. the host processor can write to this register to set or reset the request bit of a selected channel. the status of the group's software dma service re- quests can be read from this register as well. each request bit is cleared upon terminal count or exter- nal eop . the software dma requests are non-maskable and subject to priority arbitration with all other software and hardware requests. the entire register is cleared by a hardware reset. mask registers each channel has associated with it a mask bit which can be set/reset to disable/enable that chan- nel. two methods are available for setting and clear- ing the mask bits. the mask set/reset register is a write-only register which allows the host to select an individual channel and either set or reset the mask bit for that channel only. the mask read/write reg- ister is available for reading the mask bit status and for writing mask bits in groups of four. the mask bits of a group may be cleared in one step by executing the clear mask command. see the dma programming section for details. a hardware reset sets all of the channel mask bits, disabling all channels. status register the status register is a read-only register which con- tains the terminal count (tc) and service request status for a group. four bits indicate the tc status and four bits indicate the hardware request status for the four channels in the group. the tc bits are set when the byte count expires, or when an exter- nal eop is asserted. these bits are cleared by read- ing from the status register. the service request bit for a channel indicates when there is a hardware dma request (dreqn) asserted for that channel. when the request has been removed, the bit is cleared. bus size register this write-only register is used to define the bus size of the target and requester of a selected channel. the bus sizes programmed will be used to dictate the sizes of the data paths accessed when the dma channel is active. the values programmed into this register affect the operation of the temporary regis- ter. any byte-assembly required to make the trans- fers using the specified data path widths will be done in the temporary register. the bus size register of the target is used as an increment/decrement value for the byte counter and target address when in the fly-by mode. upon reset, all channels default to 8-bit targets and 8-bit requesters. chaining register as a command or write register, the chaining regis- ter is used to enable or disable the chaining mode for a selected channel. chaining can either be dis- abled or enabled for an individual channel, indepen- dently of the chaining mode status of other chan- nels. after a hardware reset, all channels default to chaining disabled. when read by the host, the chaining register pro- vides the status of the chaining interrupt of each of the channels. these interrupt status bits are cleared when the new buffer information has been loaded. 3.5.2 channel registers each channel has three individually programmable registers necessary for the dma process; they are the base byte count, base target address, and base requester address registers. the 24-bit base 42
M82380 byte count register contains the number of bytes to be transferred by the channel. the 32-bit base tar- get address register contains the beginning ad- dress (memory or i/o) of the target device. the 32- bit base requester address register contains the base address (memory or i/o) of the device which is to request dma service. three more registers for each dma channel exist within the dma controller which are directly related to the registers mentioned above. these registers contain the current status of the dma process. they are the current byte count register, the current tar- get address, and the current requester address. it is these registers which are manipulated (increment- ed, decremented, or held constant) by the M82380 dma controller during the dma process. the cur- rent registers are loaded from the base registers. the base registers are loaded when the host proc- essor writes to the respective channel register ad- dresses. depending on the mode in which the chan- nel is operating, the current registers are typically loaded in the same operation. reading from the channel register addresses yields the contents of the corresponding current register. to maintain compatibility with software which ac- cesses an 8237a, a byte pointer flip-flop is used to control access to the upper and lower bytes of some words of the channel registers. these words are accessed as byte pairs at single port addresses. the byte pointer flip-flop acts as a one-bit pointer which is toggled each time a qualifying channel register byte is accessed. it always points to the next logical byte to be accessed of a pair of bytes. the channel registers are arranged as pairs of words, each pair with its own port address. address- ing the port with the byte pointer flip-flop reset ac- cesses the least significant byte of the pair. the most significant byte is accessed when the byte pointer is set. for compatibility with existing 8237a designs, there is one exception to the above statements about the byte pointer flip-flop. the third byte (bits 16 23) of the target address is accessed through its own port address. the byte pointer flip-flop is not affected by any accesses to this byte. the upper eight bits of the byte count register are cleared when the least significant byte of the regis- ter is loaded. this provides compatibility with soft- ware which accesses an 8237a. the 8237a has 16-bit byte count registers. 3.5.3 temporary registers each channel has a 32-bit temporary register used for temporary data storage during two-cycle dma transfers. it is this register in which any necessary byte assembly and disassembly of non-aligned data is performed. figure 35 shows how a block of data will be moved between memory locations with differ- ent boundaries. note that the order of the data does not change. source destination 20h a 50h 21h b 51h 22h c 52h 23h d 53h a 24h e 54h b 25h f 55h c 26h g 56h d 27h 57h e 58h f 59h g 5ah target e source e 00000020h requester e destination e 00000053h byte count e 000006h figure 35. transfer of data between memory locations with different boundaries. this will be the result, independent of data path width. if the destination is the requester and an early pro- cess termination has been indicated by the eop sig- nal or dreqn inactive in the demand mode, the temporary register is not affected. if data remains in the temporary register due to differences in data path widths of the target and requester, it will not be transferred or otherwise lost, but will be stored for later transfer. if the destination is the target and the eop signal is sensed active during the requester access of a transfer, the dma controller will complete the trans- fer by sending to the target whatever information is in the temporary register at the time of process termination. this implies that the target could be accessed with partial data. for this reason it is ad- visable to have an i/o device designated as a re- quester, unless it is capable of handling partial data transfers. 43
M82380 3.6 dma controller programming programming a dma channel to perform a needed dma function is in general a four step process. first the global attributes of the dma controller are pro- grammed via the two command registers. these global attributes include: priority levels, channel group enables, priority mode, and dreqn/eop in- put sampling. the second step involves setting the operating modes of the particular channel. the mode regis- ters are used to define the type of transfer and the handshaking modes. the bus size register and chaining register may also need to be programmed in this step. the third step is setting up the channel is to load the base registers in accordance with the needs of the operating modes chosen in step two. the current registers are automatically loaded from the base registers, if required by the buffer transfer mode in effect. the information loaded and the order in which it is loaded depends on the operating mode. a channel used for cascading, for example, needs no buffer information and this step can be skipped en- tirely. the last step is to enable the newly programmed channel using one of the mask registers. the chan- nel is then available to perform the desired data transfer. the status of the channel can be observed at any time through the status register, mask reg- ister, chaining register, and software request reg- ister. once the channel is programmed and enabled, the dma process may be initiated in one of two ways, either by a hardware dma request (dreqn) or a software request (software request register). once programmed to a particular process/mode configuration, the channel will operate in that config- uration until programmed otherwise. for this reason, restarting a channel after the current buffer expires does not require complete reprogramming of the channel. only those parameters which have changed need to be reprogrammed. the byte count register is always changed and must be repro- grammed. a target or requester address register which is incremented or decremented should be re- programmed also. 3.6.1 buffer processes the buffer process is determined by the auto-initial- ize bit of mode register i and the chaining register. if auto-initialize is enabled, chaining should not be used. single buffer process the single buffer process is programmed by dis- abling chaining via the chaining register and pro- gramming mode register i for non-auto-initialize. buffer auto-initialize process setting the auto-initialize bit in mode register i is all that is necessary to place the channel in this mode. buffer auto-initialize must not be enabled simulta- neous to enabling the buffer chaining mode as this will have unpredictable results. once the base registers are loaded, the channel is ready to be enabled. the channel will reload its cur- rent registers from the base registers each time the current buffer expires, either by an expired byte count or an external eop . buffer chaining process the buffer chaining process is entered into from the single buffer process. the mode registers should be programmed first, with all of the transfer modes defined as if the channel were to operate in the sin- gle buffer process. the channel's base and current registers are then loaded. when the channel has been set up in this way, and the chaining interrupt service routine is in place, the chaining process can be entered by programming the chaining register. figure 36 illustrates the buffer chaining process. 44
M82380 an interrupt (irq1) will be generated immediately af- ter the chaining process is entered, as the channel then perceives the base registers as empty and in need of reloading. it is important to have the inter- rupt service routine in place at the time the chaining process is entered into. the interrupt request is re- moved when the most significant byte of the base target address is loaded. the interrupt will occur again when the first buffer expires and the current registers are loaded from the base registers. the cycle continues until the chaining process is disabled, or the host fails to re- spond to irq1 before the current buffer expires. 271070 35 figure 36. flow of events in the buffer chaining process exiting the chaining process can be done by reset- ting the chaining mode register. if an interrupt is pending for the channel when the chaining register is reset, the interrupt request will be removed. the chaining process can be temporarily disabled by setting the channel's mask bit in the mask register. the interrupt service routine for irq1 has the re- sponsibility of reloading the base register as neces- sary. it should check the status of the channel to determine the cause of channel expiration, etc. it should also have access to operating system infor- mation regarding the channel, if any exists. the irq1 service routine should be capable of determin- ing whether the chain should be continued or termi- nated and act on that information. 3.6.2 data transfer modes the data transfer modes are selected via mode register i. the demand, single, and block modes are selected by bits d6 and d7. the individual trans- fer type (fly-by vs two-cycle, read-write-verify, and i/o vs memory) is programmed through both of the mode registers. 3.6.3 cascaded bus masters the cascade mode is set by writing ones to d7 and d6 of mode register i. when a channel is pro- grammed to operate in the cascade mode, all of the other modes associated with mode registers i and ii are ignored. the priority and dreqn/eop defini- tions of the command registers will have the same effect on the channel's operation as any other mode. 3.6.4 software commands there are five port addresses which, when written to, command certain operations to be performed by the M82380 dma controller. the data written to these locations is not of consequence, writing to the location is all that is necessary to command the M82380 to perform the indicated function. following are descriptions of the command function. 45
M82380 clear byte pointer flip-flopelocation 000ch resets the byte pointer flip-flop. this command should be performed at the beginning of any access to the channel registers in order to be assured of beginning at a predictable place in the register pro- gramming sequence. master clearelocation 000dh all dma functions are set to their default states. this command is the equivalent of a hardware reset to the dma controller. functions other than those in the dma controller section of the M82380 are not affected by this command. clear mask register echannels 0 3elocation 000eh channels 4 7elocation 00ceh this command simultaneously clears the mask bits of all channels in the addressed group, enabling all of the channels in the group. clear tc interrupt requestelocation 001eh this command resets the terminal count interrupt request flip-flop. it is provided to allow the pro- gram which made a software dma request to ac- knowledge that it has responded to the expiration of the requested channel(s). 3.7 register definitions the following diagrams outline the bit definitions and functions of the M82380 dma controller's status and control registers. the function and program- ming of the registers is covered in the previous sec- tion on dma controller programming. an entry of `x' as a bit value indicates ``don't care.'' channel registers (read current, write base) channel register name address byte bits (hex) pointer accessed channel 0 target address 00 0 0 7 1 815 87 x 1623 10 0 2431 byte count 01 0 0 7 1 815 11 0 1623 requester address 90 0 0-7 1 815 91 0 1623 1 2431 channel 1 target address 02 0 0 7 1 815 83 x 1623 12 0 2431 byte count 03 0 0 7 1 815 13 0 1623 requester address 92 0 0-7 1 815 93 0 1623 1 2431 46
M82380 channel registers (read current, write base) channel register name address byte bits (hex) pointer accessed channel 2 target address 04 0 0 7 1 815 81 x 1623 14 0 2431 byte count 05 0 0 7 1 815 15 0 1623 requester address 94 0 0-7 1 815 95 0 1623 1 2431 channel 3 target address 06 0 0 7 1 815 82 x 1623 16 0 2431 byte count 07 0 0 7 1 815 17 0 1623 requester address 96 0 0-7 1 815 97 0 1623 1 2431 channel 4 target address c0 0 0 7 1 815 8f x 1623 d0 0 2431 byte count c1 0 0 7 1 815 d1 0 1623 requester address 98 0 0-7 1 815 99 0 1623 1 2431 channel 5 target address c2 0 0 7 1 815 8b x 1623 d2 0 2431 byte count c3 0 0 7 1 815 d3 0 1623 requester address 9a 0 0-7 1 815 9b 0 1623 1 2431 47
M82380 channel registers (read current, write base) channel register name address byte bits (hex) pointer accessed channel 6 target address c4 0 0 7 1 815 89 x 1623 d4 0 2431 byte count c5 0 0 7 1 815 d5 0 1623 requester address 9c 0 0-7 1 815 9d 0 1623 1 2431 channel 7 target address c6 0 0 7 1 815 8a x 1623 d6 0 2431 byte count c7 0 0 7 1 815 d7 0 1623 requester address 9e 0 0-7 1 815 9f 0 1623 1 2431 command register i (write only) port addressechannels 0 3e0008h channels 4 7e00c8h 271070 36 command register ii (write only) port addressesechannels 0 3e-001ah channels 4 7e00dah 271070 37 48
M82380 mode register i (write only) port addressesechannels 0 3e000bh channels 4 7e00cbh 271070 38 * target and requester decrement is allowed only for byte transfers. mode register ii (write only) port addressesechannels 0 3e001bh channels 4 7e00dbh 271070 39 * target and requester decrement is allowed only for byte transfers. 49
M82380 software request register (read/write) port addressesechannels 0 3e0009h channels 4 7e00c9h write format: software dma service request 271070 40 read format: software requests pending 271070 41 mask set/reset register individual channel mask (write only) port addressesechannels 0 3e000ah channels 4 7e00cah 271070 42 50
M82380 mask read/write register group channel mask (read/write) port addressesechannels 0 3e000fh channels 4 7e00cfh 271070 43 status register channel process status (read only) port addressesechannels 0 3e0008h channels 4 7e00c8h 271070 44 bus size register set data path width (write only) port addressesechannels 0 3e0018h channels 4 7e00d8h 271070 45 bus size encoding: 00 e reserved by intel 10 e 16-bit bus 01 e 32-bit bus 11 e 8-bit bus 51
M82380 chaining register (read/write) port addressesechannels 0 3e0019h channels 4 7e00d9h write format: set chaining mode 271070 46 read format: channel interrupt status 271070 47 52
M82380 4.0 programmable interrupt controller 4.1 functional description the M82380 programmable interrupt controller (pic) consists of three enhanced m8259a interrupt contollers. these three controllers together provide 15 external and 5 internal interrupt request inputs. each external request input can be cascaded with an additional m8259a slave collector. this scheme allows the M82380 to support a maximum of 120 (15 x 8) external interrupt request inputs. following one or more interrupt requests, the M82380 pic issues an interrupt signal to the i386 processor. when the i386 host processor responds with an interrupt acknowledge signal, the pic will ar- bitrate between the pending interrupt requests and place the interrupt vector associated with the high- est priority pending request on the data bus. the major enhancement in the M82380 pic over the m8259a is that each of the interrupt request inputs can be individually programmed with its own inter- rupt vector, allowing more flexibility in interrupt vec- tor mapping. 4.1.1 internal block diagram the block diagram of the M82380 programmable in- terrupt controller is shown in figure 37. internally, the pic consists of three m8259a banks: a, b and c. the three banks are cascaded to one another: c is cascaded to b, b is cascaded to a. the int output of bank a is used externally to interrupt the i386 processor. bank a has nine interrupt request inputs (two are unused), and banks b and c have eight interrupt request inputs. of the fifteen external interrupt re- quest inputs, two are shared by other functions. spe- cifically, the interrupt request 3 input (irq3 ) can be used as the timer 2 output (tout2 ). this pin can be used in three different ways: irq3 input only, tout2 output only, or using tout2 to generate an irq3 interrupt request. also, the interrupt request 9 input (irq9 ) can be used as dma request 4 input (dreq4). typically, only irq9 or dreq4 can be used at a time. 271070 48 note: masking irq1.5 also masks irq2 . figure 37. interrupt controller block diagram 53
M82380 4.1.2 interrupt controller banks all three banks are identical, with the exception of the irq1.5 on bank a. therefore, only one bank will be discussed. in the M82380 pic, all external re- quests can be cascaded into and each interrupt con- troller bank behaves like a master. as compared to the m8259a, the enhancements in the banks are: e all interrupt vectors are individually programma- ble. (in the m8259a, the vectors must be pro- grammed in eight consecutive interrupt vector lo- cations.) e the cascade address is provided on the data bus (d0 d7). (in the m8259a, three dedicated control signals (cas0, cas1, cas2) are used for master/slave cascading.) the block diagram of a bank is shown in figure 38. as can be seen from this figure, the bank consists of six major blocks: the interrupt request register (irr), the in-service register (isr), the interrupt mask register (imr), the priority resolver (pr), the vector register (vr), and the control logic. the functional description of each block follows. 271070 49 figure 38. interrupt bank block diagram 54
M82380 interrupt request (irr) and in-service register (isr) the interrupts at the interrupt request (irq) input lines are handled by two registers in cascade, the interrupt request register (irr) and the in-service register (isr). the irr is used to store all interrupt levels which are requesting service; and the isr is used to store all interrupt levels which are being serviced. priority resolver (pr) this logic block determines the priorities of the bits set in the irr. the highest priority is selected and strobed into the corresponding bit of the isr during an interrupt acknowledge cycle. interrupt mask register (imr) the imr stores the bits which mask the interrupt lines to be masked (disabled). the imr operates on the irr. masking of a higher priority input will not affect the interrupt request lines of lower priority. vector registers (vr) this block contains a set of vector registers, one for each interrupt request line, to store the pre-pro- grammed interrupt vector number. the correspond- ing vector number will be driven onto the data bus of the M82380 during the interrupt acknowledge cy- cle. control logic the control logic coordinates the overall operations of the other internal blocks within the same bank. this logic will drive the interrupt output signal (int) high when one or more unmasked interrupt inputs are active (low). the int output signal goes direct- ly to the i386 processor (in bank a) or to another bank to which this bank is cascaded (see figure 37). also, this logic will recognize an interrupt acknowl- edge cycle (via m/io , d/c and w/r signals). during this bus cycle, the control logic will enable the cor- responding vector register to drive the interrupt vector onto the data bus. in bank a, the control logic is also responsible for handling the special icw2 interrupt request input (irq1.5 ). 4.2 interface signals 4.2.1 interrupt inputs there are 15 external interrupt request inputs and 5 internal interrupt requests. the external request in- puts are: irq3 , irq9 , irq11 to irq23 . they are shown in bold arrows in figure 37. all irq inputs are active low and they can be programmed (via a con- trol bit in the initialization command word 1 (icw1)) to be either edge-triggered or level-triggered. in or- der to be recognized as a valid interrupt request, the interrupt input must be active (low) until the first inta cycle (see bus functional description). note that all 15 external interrupt request inputs have weak internal pull-up resistors. as mentioned earlier, an m8259a can be cascaded to each external interrupt input to expand the inter- rupt capacity to a maximum of 120 levels. also, two of the interrupt inputs are dual functions: irq3 can be used as timer 2 output (tout2 ) and irq9 can be used as dreq4 input. irq3 is a bidirectional dual function pin. this interrupt request input is wired-or with the output of timer 2 (tout2 ). if only irq3 function is to be used, timer 2 should be pro- grammed so that out2 is low. note that tout2 can also be used to generate an interrupt request to irq3 input. the five internal interrupt requests serve special system functions. they are shown in table 8. the following paragraphs describe these interrupts. table 8. M82380 internal interrupt requests interrupt request interrupt source irq0 timer 3 output (tout3 ) irq8 timer 0 output (tout0 ) irq1 dma chaining request irq4 dma terminal count irq1.5 icw2 written timer 0 and timer 3 interrupt requests irq8 and irq0 interrupt requests are initiated by the output of timers 0 and 3, respectively. each of these requests is generated by an edge-detector flip-flop. the flip-flops are activated by the following condi- tions: sete rising edge of timer output (tout); cleare interrupt acknowledge for this request; or request is masked (disabled); or hardware reset. 55
M82380 chaining and terminal count interrupts these interrupt requests are generated by the M82380 dma controller. the chaining request (irq1 ) indicates that the dma base register is not loaded. the terminal count request (irq4 ) indi- cates that a software dma request was cleared. icw2 interrupt request whenever an initialization control word 2 (icw2) is written to a bank, a special icw2 interrupt request is generated. the interrupt will be cleared when the newly programmed icw2 register is read. this in- terrupt request is in bank a at level 1.5. this inter- rupt request is internally ored with the cascaded request from bank b and is always assigned a high- er priority than the cascaded request. this special interrupt is provided to support compati- bility with the original m8259a. a detailed description of this interrupt is discussed in the programming section. default interrupt during an interrupt acknowledge cycle, if there is no active pending request, the pic will automatically generate a default vector. this vector corresponds to the irq7 vector in bank a. 4.2.2 interrupt output (int) the int output pin is taken directly from bank a. this signal should be tied to the maskable interrupt request (intr) of the i386 processor. when this signal is active (high), it indicates that one or more internal/external interrupt requests are pending. the i386 processor is expected to respond with an inter- rupt acknowledge cycle. 4.3 bus functional description the int output of bank a will be activated as a result of any unmasked interrupt request. this may be a non-cascaded or cascaded request. after the pic has driven the int signal high, i386 processor will respond by performing two interrupt acknowledge cycles. the timing diagram in figure 39 shows a typi- cal interrupt acknowledge process between the M82380 and the i386 cpu. 271070 50 note: what is actually driven on the data bus depends on if the current interrupt request is a slave request. inta cycle 1 inta cycle 2 non-slave request 00h vector slave request slave address high impedance * * slave will place a vector at this time. figure 39. interrupt acknowledge cycle 56
M82380 after activating the int signal, the M82380 monitors the status lines (m/io , d/c , w/r ) and waits for the i386 processor to initiate the first interrupt acknowl- edge cycle. in the i386 processor environment, two successive interrupt acknowledge cycles (inta) marked by m/io e low, d/c e low, and w/r e low are performed. during the first inta cycle, the pic will determine the highest priority request. as- suming this interrupt input has no external slave controller cascaded to it, the M82380 will drive the data bus with 00h in the first inta cycle. during the second inta cycle, the M82380 pic will drive the data bus with the corresponding preprogrammed in- terrupt vector. if the pic determines (from the icw3) that this inter- rupt input has an external slave controller cascaded to it, it will drive the data bus with the specific slave cascade address (instead of 00h) during the first inta cycle. this slave cascade address is the pre- programmed content in the corresponding vector register. this means that no slave address should be chosen to be 00h. note that the slave address and interrupt vector are different interpretations of the same thing. they are both the contents of the programmable vector register. during the second inta cycle, the data bus will be floated so that the external slave controller can drive its interrupt vec- tor on the bus. since the slave interrupt controller resides on the system bus, bus transceiver enable and direction control logic must take this into consid- eration. in order to have a successful interrupt service, the interrupt request input must be held active (low) until the beginning of the first interrupt acknowledge cycle. if there is no pending interrupt request when the first inta cycle is generated, the pic will gener- ate a default vector, which is the irq7 vector (bank a level 7). according to the bus cycle definition of the i386 processor, there will be four bus idle states be- tween the two interrupt acknowledge cycles. these idle bus cycles will be initiated by the i386 processor. also, during each interrupt acknowledge cycle, the internal wait state generator of the M82380 will au- tomatically generate the required number of wait states for internal delays. 4.4 mode of operation a variety of modes and commands are available for controlling the M82380 pic. all of them are pro- grammable; that is, they may be changed dynamical- ly under software control. in fact, each bank can be programmed individually to operate in different modes. with these modes and commands, many possible configurations are conceivable, giving the user enough versatility for almost any interrupt con- trolled application. this section is not intended to show how the M82380 pic can be programmed. rather, it de- scribes the operation in different modes. 4.4.1 end-of-interrupt upon completion of an interrupt service routine, the interrupted bank needs to be notified so its isr can be updated. this allows the pic to keep track of which interrupt levels are in the process of being serviced and their relative priorities. three different end-of-interrupt (eoi) formats are available. they are: non-specific eoi command, specific eoi com- mand, and automatic eoi mode. selection of which eoi to use is dependent upon the interrupt opera- tions the user wishes to perform. if the M82380 is not programmed in the automatic eoi mode, an eoi command must be issued by the i386 processor to the specific M82380 pic control- ler bank. also, if this controller bank is cascaded to another internal bank, an eoi command must also be sent to the bank to which this bank is cascaded. for example, if an interrupt request of bank c in the M82380 pic is serviced, an eoi should be written into bank c, bank b and bank a. if the request comes from an external interrupt controller cascad- ed to bank c, then an eoi should be written into the external controller as well. non-specific eoi command a non-specific eoi command sent from the i386 processor lets the M82380 pic bank know when a service routine has been completed, without specifi- cation of its exact interrupt level. the respective in- terrupt bank automatically determines the interrupt level and resets the correct bit in the isr. to take advantage of the non-specific eoi, the in- terrupt bank must be in a mode of operation in which it can predetermine its in-service routine levels. for this reason, the non-specific eoi command should only be used when the most recent level acknowl- edged and serviced is always the highest priority lev- el (i.e., in the fully nested mode structure to be de- scribed below). when the interrupt bank receives a non-specific eoi command, it simply resets the highest priority isr bit to indicate that the highest priority routine in service is finished. special consideration should be taken when decid- ing to use the non-specific eoi command. here are two operating conditions in which it is best not 57
M82380 used since the fully nested mode structure will be destroyed: e using the set priority command within an inter- rupt service routine. e using a special mask mode. these conditions are covered in more detail in their own sections, but are listed here for reference. specific eoi command unlike a non-specific eoi command which automat- ically resets the highest priority isr bit, a specific eoi command specifies an exact isr bit to be reset. any one of the irq levels of an interrupt bank can be specified in the command. the specific eoi command is needed to reset the isr bit of a completed service routine whenever the interrupt bank is not able to automatically determine it. the specific eoi command can be used in all conditions of operation, including those that prohibit non-specific eoi command usage mentioned above. automatic eoi mode when programmed in the automatic eoi mode, the m80386 no longer needs to issue a command to notify the interrupt bank it has completed an inter- rupt routine. the interrupt bank accomplishes this by performing a non-specific eoi automatically at the end of the second inta cycle. special consideration should be taken when decid- ing to use the automatic eoi mode because it may disturb the fully nested mode structure. in the auto- matic eoi mode, the isr bit of a routine in service is reset right after it is acknowledged, thus leaving no designation in the isr that a service routine is being executed. if any interrupt request within the same bank occurs during this time and interrupts are en- abled, it will get serviced regardless of its priority. therefore, when using this mode, the m80386 should keep its interrupt request input disabled dur- ing execution of a service routine. by doing this, higher priority interrupt levels will be serviced only after the completion of a routine in service. this guideline restores the fully nested mode structure. however, in this scheme, a routine in service cannot be interrupted since the host's interrupt request in- put is disabled. 4.4.2 interrupt priorities the M82380 pic provides various methods for ar- ranging the interrupt priorities of the interrupt re- quest inputs to suit different applications. the follow- ing sub-sections explain these methods in detail. fully nested mode the fully nested mode of operation is a general pur- pose priority mode. this mode supports a multi-level interrupt structure in which all of the interrupt re- quest (irq) inputs within one bank are arranged from highest to lowest. unless otherwise programmed, the fully nested mode is entered by default upon initialization. at this time, irq0 is assigned the highest priority (priority e 0) and irq7 the lowest (priority e 7). this default priority can be changed, as will be explained later in the rotating priority mode. when an interrupt is acknowledged, the highest pri- ority request is determined from the interrupt re- quest register (irr) and its vector is placed on the bus. in addition, the corresponding bit in the in-serv- ice register (isr) is set to designate the routine in service. this isr bit will remain set until the m80386 issues an end of interrupt (eoi) command immedi- ately before returning from the service routine; or alternately, if the automatic end of interrupt (aeoi) bit is set, the isr bit will be reset at the end of the second inta cycle. 58
M82380 while the isr bit is set, all further interrupts of the same or lower priority are inhibited. higher level in- terrupts can still generate an interrupt, which will be acknowledged only if the i386 processor internal in- terrupt enable flip-flop has been re-enabled (through software inside the current service routine). automatic rotationeequal priority devices automatic rotation of priorities serves in applications where the interrupting devices are of equal priority within an interrupt bank. in this kind of environment, once a device is serviced, all other equal priority pe- ripherals should be given a chance to be serviced before the original device is serviced again. this is accomplished by automatically assigning a device the lowest priority after being serviced. thus, in the worst case, the device would have to wait until all other peripherals connected to the same bank are serviced before it is serviced again. there are two methods of accomplishing automatic rotation. one is used in conjunction with the non- specific eoi command and the other is used with the automatic eoi mode. these two methods are discussed below. rotate on non-specific eoi command when the rotate on non-specific eoi command is issued, the highest isr bit is reset as in a normal non-specific eoi command. however, after it is re- set, the corresponding interrupt request (irq) level is assigned the lowest priority. other irq priorities rotate to conform to the fully nested mode based on the newly assigned low priority. figure 40 shows how the rotate on non-specific eoi command affects the interrupt priorities. as- sume the irq priorities were assigned with irq0 the highest and irq7 the lowest. irq6 and irq4 are already in service but neither is completed. being the higher priority routine, irq4 is necessarily the routine being executed. during the irq4 routine, a rotate on non-specific eoi command is executed. when this happens, bit 4 in the isr is reset. irq4 then becomes the lowest priority and irq5 becomes the highest. 271070 51 271070 52 figure 40. rotate on non-specific eoi command 59
M82380 rotate on automatic eoi mode the rotate on automatic eoi mode works much like the rotate on non-specific eoi command. the main difference is that priority rotation is done auto- matically after the second inta cycle of an interrupt request. to enter or exit this mode, a rotate-on-au- tomatic-eoi set command and rotate-on-automat- ic-eoi clear command is provided. after this mode is entered, no other commands are needed as in the normal automatic eoi mode. however, it must be noted again that when using any form of the auto- matic eoi mode, special consideration should be taken. the guideline presented in the automatic eoi mode also applies here. specific rotationespecific priority specific rotation gives the user versatile capabilities in interrupt controlled operations. it serves in those applications in which a specific device's interrupt pri- ority must be altered. as opposed to automatic ro- tation which will automatically set priorities after each interrupt request is serviced, specific rotation is completely user controlled. that is, the user selects which interrupt level is to receive the lowest or the highest priority. this can be done during the main program or within interrupt routines. two specific ro- tation commands are available to the user: set prior- ity command and rotate on specific eoi com- mand. set priority command the set priority command allows the programmer to assign an irq level the lowest priority. all other in- terrupt levels will conform to the fully nested mode based on the newly assigned low priority. rotate on specific eoi command the rotate on specific eoi command is literally a combination of the set priority command and the specific eoi command. like the set priority com- mand, a specified irq level is assigned lowest priori- ty. like the specific eoi command, a specified level will be reset in the isr. thus, this command accom- plishes both tasks in one single command. interrupt priority mode summary in order to simplify understanding the many modes of interrupt priority, table 9 is provided to bring out their summary of operations. table 9. interrupt priority mode summary interrupt operation effect on priority after eoi priority mode summary non-specific/automatic specific fully-nested mode irq0 -highest priority no change in priority. not applicable. irq7 -lowest priority highest isr bit is reset. automatic rotation interrupt level just serviced highest isr bit is reset and the not applicable. is the lowest priority. other (equal priority devices) corresponding level becomes the priorities rotate to conform lowest priority. to fully-nested mode. specific rotation user specifies the lowest not applicable. as described under priority level. other priorities (specific priority `operation summary'. rotate to conform to fully- devices) nested mode. 60
M82380 4.4.3 interrupt masking via interrupt mask register each bank in the M82380 pic has an interrupt mask register (imr) which enhances interrupt control ca- pabilities. this imr allows individual irq masking. when an irq is masked, its interrupt request is dis- abled until it is unmasked. each bit in the 8-bit imr disables one interrupt channel if it is set (high). bit 0 masks irq0, bit 1 masks irq1 and so forth. masking an irq channel will only disable the corre- sponding channel and does not affect the others op- erations. the imr acts only on the output of the irr. that is, if an interrupt occurs while its imr bit is set, this request is not `forgotten'. even with an irq input masked, it is still possible to set the irr. therefore, when the imr bit is reset, an interrupt request to the i386 processor will then be generated, providing that the irq request remains active. if the irq request is removed before the imr is reset, the default inter- rupt vector (bank a, level 7) will be generated during the interrupt acknowledge cycle. special mask mode in the fully nested mode, all irq levels of lower priority than the routine in service are inhibited. how- ever, in some applications, it may be desirable to let a lower priority interrupt request to interrupt the rou- tine in service. one method to achieve this is by using the special mask mode. working in conjunc- tion with the imr, the special mask mode enables interrupts from all levels except the level in service. this is usually done inside an interrupt service rou- tine by masking the level that is in service and then issuing the special mask mode command. once the special mask mode is enabled, it remains in effect until it is disabled. 4.4.4 edge or level interrupt triggering each bank in the M82380 pic can be programmed independently for either edge or level sensing for the interrupt request signals. recall that all irq inputs are active low. therefore, in the edge triggered mode, an active edge is defined as an input tran- sition from an inactive (high) to active (low) state. the interrupt input may remain active without gener- ating another interrupt. during level triggered mode, an interrupt request will be recognized by an active (low) input, and there is no need for edge detec- tion. however, the interrupt request must be re- moved before the eoi command is issued, or the i386 processor must be disabled to prevent a sec- ond false interrupt from occurring. in either modes, the interrupt request input must be active (low) during the first inta cycle in order to be recognized. otherwise, the default interrupt vec- tor will be generated at level 7 of bank a. 4.4.5 interrupt cascading as mentioned previously, the M82380 allows for ex- ternal slave interrupt controllers to be cascaded to any of its external interrupt request pins. the M82380 pic indicates that a external slave control- ler is to be serviced by putting the contents of the vector register associated with the particular re- quest on the i386 data bus during the first inta cycle (instead of 00h during a non-slave service). the external logic should latch the vector on the data bus using the inta status signals and use it to select the external slave controller to be serviced (see figure 41). the selected slave will then re- spond to the second inta cycle and place its vector on the data bus. this method requires that if exter- nal slave controllers are used in the system, no vec- tor should be programmed to 00h. 271070 53 figure 41. slave cascade address capturing 61
M82380 since the external slave cascade address is provid- ed on the data bus during inta cycle 1, an external latch is required to capture this address for the slave controller. a simple scheme is depicted in figure 41. special fully nested mode this mode will be used where cascading is em- ployed and the priority is to be conserved within each slave controller. the special fully nested mode is similar to the `regular' fully nested mode with the following exceptions: e when an interrupt request from a slave control- ler is in service, this slave controller is not locked out from the master's priority logic. fur- ther interrupt requests from the higher priority logic within the slave controller will be recog- nized by the M82380 pic and will initiate inter- rupts to the i386 processor. in comparing to the `regular' fully nested mode, the slave controller is masked out when its request is in service and no higher requests from the same slave control- ler can be serviced. e before exiting the interrupt service routine, the software has to check whether the interrupt serv- iced was the only request from the slave con- troller. this is done by sending a non-specific eoi command to the slave controller and then reading its in service register. if there are no requests in the slave controller, a non-specific eoi can be sent to the corresponding M82380 pic bank also. otherwise, no eoi should be sent. 4.4.6 reading interrupt status the M82380 pic provides several ways to read dif- ferent status of each interrupt bank for more flexible interrupt control operations. these include polling the highest priority pending interrupt request and reading the contents of different interrupt status reg- isters. poll command the M82380 pic supports status polling operations with the poll command. in a poll command, the pending interrupt request with the highest priority can be determined. to use this command, the int output is not used, or the i386 processor interrupt is disabled. service to devices is achieved by software using the poll command. this mode is useful if there is a routine command common to several levels so that the inta se- quence is not needed. another application is to use the poll command to expand the number of priority levels. notice that the icw2 mechanism is not supported for the poll command. however, if the poll com- mand is used, the programmable vector registers are of no concern since no inta cycle will be gener- ated. reading interrupt registers the contents of each interrupt register (irr, isr, and imr) can be read to update the user's program on the present status of the M82380 pic. this can be a versatile tool in the decision making process of a service routine, giving the user more control over interrupt operations. the reading of the irr and isr contents can be performed via the operation control word 3 by us- ing a read status register command and the con- tent of imr can be read via a simple read operation of the register itself. 4.5 register set overview each bank of the M82380 pic consists of a set of 8-bit registers to control its operations. the address map of all the registers is shown in table 10. since all three register sets are identical in functions, only one set will be described. functionally, each register set can be divided into five groups. they are: the four initialization com- mand words (icw's), the three operation control words (ocw's), the poll/interrupt request/in-serv- ice register, the interrupt mask register, and the vector registers. a description of each group fol- lows. 62
M82380 table 10. interrupt controller register address map port access register description address 20h write bank b icw1, ocw2, or ocw3 read bank b poll, request or in-service status register 21h write bank b icw2, icw3, icw4, ocw1 read bank b mask register 22h read bank b icw2 28h read/write irq8 vector register 29h read/write irq9 vector register 2ah read/write reserved 2bh read/write irq11 vector register 2ch read/write irq12 vector register 2dh read/write irq13 vector register 2eh read/write irq14 vector register 2fh read/write irq15 vector register a0h write bank c icw1, ocw2, or ocw3 read bank c poll, request or in-service status register a1h write bank c icw2, icw3, icw4, ocw1 read bank c mask register a2h read bank c icw2 a8h read/write irq16 vector register a9h read/write irq17 vector register aah read/write irq18 vector register abh read/write irq19 vector register ach read/write irq20 vector register adh read/write irq21 vector register aeh read/write irq22 vector register afh read/write irq23 vector register 30h write bank a icw1, ocw2, or ocw3 read bank a poll, request or in-service status register 31h write bank a icw2, icw3, icw4, ocw1 read bank a mask register 32h read bank icw2 38h read/write irq0 vector register 39h read/write irq1 vector register 3ah read/write irq1.5 vector register 3bh read/write irq3 vector register 3ch read/write irq4 vector register 3dh read/write reserved 3eh read/write reserved 3fh read/write irq7 vector register 63
M82380 4.5.1 initialization command words (icw) before normal operation can begin, the M82380 pic must be brought to a known state. there are four 8-bit initialization command words in each interrupt bank to setup the necessary conditions and modes for proper operation. except for the second common word (icw2) which is a read/write register, the other three are write-only registers. without going into de- tail of the bit definitions of the command words, the following subsections give a brief description of what functions each command word controls. icw1 the icw1 has three major functions. they are: e to select between the two irq input triggering modes (edge-or level-triggered); e to designate whether or not the interrupt bank is to be used alone or in the cascade mode. if the cascade mode is desired, the interrupt bank will accept icw3 for further cascade mode program- ming. otherwise, no icw3 will be accepted; e to determine whether or not icw4 will be issued; that is, if any of the icw4 operations are to be used. icw2 icw2 is provided for compatibility with the m8259a only. its contents do not affect the operation of the interrupt bank in any way. whenever the icw2 of any of the three banks is written into, an interrupt is generated from bank a at level 1.5. the interrupt request will be cleared after the icw2 register has been read by the m80386. the user is expected to program the corresponding vector register or to use it as an indicator that an attempt was made to alter the contents. note that each icw2 register has dif- ferent addresses for read and write operations. icw3 the interrupt bank will only accept an icw3 if pro- grammed in the external cascade mode (as indicat- ed in icw1). icw3 is used for specific programming within the cascade mode. the bits in icw3 indicate which interrupt request inputs have a slave cascad- ed to them. this will subsequently affect the inter- rupt vector generation during the interrupt acknowl- edge cycles as described previously. icw4 the icw4 is accepted only if it was selected in icw1. this command word register serves two func- tions: e to select either the automatic eoi mode or soft- ware eoi mode; e to select if the special nested mode is to be used in conjunction with the cascade mode. 4.5.2 operation control words (ocw) once initialized by the icw's, the interrupt banks will be operating in the fully nested mode by default and they are ready to accept interrupt requests. however, the operations of each interrupt bank can be further controlled or modified by the use of ocw's. three ocw's are available for programming various modes and commands. note that all ocw's are 8-bit write-only registers. the modes and operations controlled by the ocw's are: e fully nested mode; e rotating priority mode; e special mask mode; e poll mode; e eoi commands; e read status commands. ocw1 ocw1 is used solely for masking operations. it pro- vides a direct link to the interrupt mask register (imr). the m80386 can write to this ocw register to enable or disable the interrupt inputs. reading the pre-programmed mask can be done via the interrupt mask register which will be discussed shortly. ocw2 ocw2 is used to select end-of-interrupt, automatic priority rotation, and specific priority rotation oper- ations. associated commands and modes of these operations are selected using the different combina- tions of bits in ocw2. specifically, the ocw2 is used to: e designate an interrupt level (0 7) to be used to reset a specific isr bit or to set a specific priori- ty. this function can be enabled or disabled; e select which software eoi command (if any) is to be executed (i.e., non-specific or specific eoi); e enable one of the priority rotation operations (i.e., rotate on non-specific eoi, rotate on au- tomatic eoi, or rotate on specific eoi). ocw3 there are three main categories of operation that ocw3 controls. that are summarized as follows: 64
M82380 e to select and execute the read status register commands, either reading the interrupt request register (irr) or the in-service register (isr); e to issue the poll command. the poll command will override a read register command if both functions are enabled simultaneously; e to set or reset the special mask mode. 4.5.3 poll/interrupt request/in-service status register as the name implies, this 8-bit read-only register has multiple functions. depending on the command is- sued in the ocw3, the content of this register re- flects the result of the command executed. for a poll command, the register read contains the binary code of the highest priority level requesting service (if any). for a read irr command, the register con- tent will show the current pending interrupt re- quest(s). finally, for a read isr command, this reg- ister will specify all interrupt levels which are being serviced. 4.5.4 interrupt mask register (imr) this is a read-only 8-bit register which, when read, will specify all interrupt levels within the same bank that are masked. 4.5.5 vector register (vr) each interrupt request input has an 8-bit read/write programmable vector register associated with it. the registers should be programmed to contain the inter- rupt vector for the corresponding request. the con- tents of the vector register will be placed on the data bus during the inta cycles as described previ- ously. 4.6 programming programming the M82380 pic is accomplished by using two types of command words: icw's and ocw's. all modes and commands explained in the previous sections are programmable using the icw's and ocw's. the icw's are issued from the m80386 in a sequential format and are used to set- up the banks in the M82380 pic in an initial state of operation. the ocw's are issued as needed to vary and control the M82380 pic's operations. both icw's and ocw's are sent by the i386 proces- sor to the interrupt banks via the data bus. each bank distinguishes between the different icw's and ocw's by the i/o address map, the sequence they are issued (icw's only), and by some dedicated bits among the icw's and ocw's. all three interrupt banks are programmed in a similar way. therefore, only a single bank will be described. 4.6.1 initialization (icw) before normal operation can begin, each bank must be initialized by programming a sequence of two to four bytes written into the icw's. figure 42 shows the initialization flow for an interrupt bank. both icw1 and icw2 must be issued for any form of operation. however, icw3 and icw4 are used only if designated in icw1. once initialized, if any programming changes within the icw's are to be made, the entire icw sequence must be repro- grammed, not just an individual icw. note that although the icw2's in the M82380 pic do not affect the bank's operation, they still must be programmed in order to preserve the compatibility with the m8259a. the contents programmed are not relevant to the overall operations of the interrupt banks. also, whenever one of the three icw2's is programmed, an interrupt level 1.5 in bank a will be generated. this interrupt request will be cleared upon reading of the icw2 registers. since the three icw2's share the same interrupt level and the sys- tem may not know the origin of the interrupt, all three icw2's must be read. however, it is not necessary to provide an interrupt service routine for the icw2 interrupt. one way to avoid this is as follows. at the beginning of the initial- ization of the interrupt banks, the i386 processor in- terrupt should be disabled. after each icw2 register write operation is performed during the initialization, the corresponding icw2 register is read. this read operation will clear the interrupt request of the M82380. at the end of the initialization, the i386 processor interrupt is re-enabled. with this method, the i386 processor will not detect the icw2 interrupt request, thus eliminating the need of an interrupt service routine. certain internal setup conditions occur automatically within the interrupt bank after the first icw (icw1) has been issued. they are: e the edge sensitive circuit is reset, which means that following initialization, an interrupt request input must make a high-to-low transition to generate an interrupt; e the interrupt mask register (imr) is cleared; that is, all interrupt inputs are enabled; e irq7 input of each bank is assigned priority 7 (lowest); e special mask mode is cleared and status read is set to irr; e if no icw4 is needed, then no automatic-eoi is selected. 65
M82380 271070 54 * icw2 vector address must be programmed now. other vector addresses may be programmed via icw2 interrupt service routine. figure 42. initialization sequence 4.6.2 vector registers (vr) each interrupt request input has a separate vector register. these vector registers are used to store the pre-programmed vector number corresponding to their interrupt sources. in order to guarantee prop- er interrupt handling, all vector registers must be programmed with the predefined vector numbers. since an interrupt request will be generated whenev- er an icw2 is written during the initialization se- quence, it is important that the vector register of irq1.5 in bank a should be initialized and the inter- rupt service routine of this vector is set up before the icw's are written. 4.6.3 operation control words (ocw) after the icw's are programmed, the operations of each interrupt controller bank can be changed by writing into the ocw's as explained before. there is no special programming sequence required for the ocw's. any ocw may be written at any time in or- der to change the mode of or to perform certain op- erations on the interrupt banks. read status and poll commands (ocw3) since the reading of irr and isr status as well as the result of a poll command are available on the 66
M82380 same read-only status register, a special read status/poll command must be issued before the poll/interrupt request/in-service status register is read. this command can be specified by writing the required control word into ocw3. as mentioned ear- lier, if both the poll command and the status read command are enabled simultaneously, the poll command will override the status read. that is, af- ter the command execution, the status register will contain the result of the poll command. note that for reading irr and isr, there is no need to issue a read status command to the ocw3 ev- ery time the irr or isr is to be read. once a read status command is received by the interrupt bank, it `remembers' which register is selected. however, this is not true when the poll command is used. in the poll command, after the ocw3 is written, the M82380 pic treats the next read to the status reg- ister as an interrupt acknowledge. this will set the appropriate is bit if there is a request and read the priority level. interrupt request input status remains unchanged from the poll command to the status read. in addition to the above read commands, the inter- rupt mask register (imr) can also be read. when read, this register reflects the contents of the pre- programmed ocw1 which contains information on which interrupt request(s) is(are) currently disabled. 4.7 register bit definition initialization command word 1 (icw1) 271070 55 initialization command word 2 (icw2) 271070 56 67
M82380 initialization command word 3 (icw3) icw3 for bank a: 271070 57 icw3 for bank b: 271070 58 icw3 for bank c: 271070 59 initialization command word 4 (icw4) 271070 60 operation control word 1 (ocw1) 271070 61 68
M82380 operation control word 2 (ocw2) 271070 62 operation control word 3 (ocw3) 271070 63 esmmeenable special mask mode. when this bit is set to 1, it enables the smm bit to set or reset the special mask mode. when this bit is set to 0, smm bit becomes don't care. smmespecial mask mode. if esmm e 1 and smm e 1, the interrupt controller bank will enter special mask mode. if esmm e 1 and smm e 0, the bank will revert to normal mask mode. when esmm e 0, smm has no effect. poll/interrupt request/in-service status register poll command status 271070 64 69
M82380 interrupt request status 271070 65 note: although all interrupt request inputs are active low, the internal logical will invert the state of the pins so that when there is a pending interrupt request at the input, the corresponding irq bit will be set to high in the interrupt request status register. in-service status 271070 66 vector register (vr) 271070 67 4.8 register operational summary for ease of reference, table 11 gives a summary of the different operating modes and commands with their corresponding registers. table 11. register operational summary operational command bits description words fully nested mode ocw-default e non-specific eoi command ocw2 eoi specific eoi command ocw2 sl, eoi, lol2 automatic eoi mode icw1, icw4 ic4, aeoi rotate on non-specific ocw2 eoi eoi command rotate on automatic ocw2 r, sl, eoi eoi mode set priority command ocw2 l0 l2 rotate on specific ocw2 r, sl, eoi eoi command interrupt mask register ocw1 m0 m7 special mask mode ocw3 esmm, smm level triggered mode icw1 ltim edge triggered mode icw1 ltim read register command, irr ocw3 rr, ris read register command, isr ocw3 rr, ris red imr imr m0 m7 poll command ocw3 p special fully nested mode icw2, icw4 ic4, sfnm 70
M82380 5.0 programmable interval timer 5.1 functional description the M82380 contains four independently program- mable interval timers: timer 0 3. all four timers are functionally compatible to the intel m82c54. the first three timers (timer 0 2) have specific func- tions. the fourth timer, timer 3, is a general purpose timer. table 12 depicts the functions of each timer. a brief description of each timer's function follows. table 12. programmable interval timer functions timer output function 0 irq8 event based irq8 generator 1 tout1/ref gen. purpose/dram refresh req. 2 tout2 /irq3 gen. purpose/speaker out/irq3 3 tout3 gen. purpose/irq0 generator timer 0e event based irq8 generator timer 0 is intended to be used as an event counter. the output of this timer will generate an interrupt request 8 (irq8) upon a rising edge of the timer output (tout0). typically, this timer is used to im- plement a time-of-day clock or system tick. the tim- er 0 output is not available as an external signal. timer 1e general purpose/dram refresh request the output of timer 1, tout1, can be used as a general purpose timer or as a dram refresh re- quest signal. the rising edge of this output creates a dram refresh request to the M82380 dram re- fresh controller. upon reset, the refresh request function is disabled, and the output pin is the timer 1 output. timer 2egeneral purpose/speaker out/irq3 the timer 2 output, tout2 , could be used to sup- port tone generation to an external speaker. this pin is a bidirectional signal. when used as an input, a logic low asserted at this pin will generate an inter- rupt register 3 (irq3 ) (see programmable interrupt controller). 271070 68 figure 43. block diagram of programmable interval timer 71
M82380 timer 3egeneral purpose/interrupt request 0 generator the output of timer 3 is fed to an edge detector and generates an interrupt request 0 (irq0) in the M82380. the inverted output of this timer (tout3 ) is also available as an external signal for general purpose use. 5.1.1 internal architecture the functional block diagram of the programmable interval timer section is shown in figure 43. follow- ing is a description of each block. data buffer & read/write logic this part of the programmable interval timer is used to interface the four timers to the M82380 internal bus. the data buffer is for transferring commands and data between the 8-bit internal bus and the timers. the read/write logic accepts inputs from the inter- nal bus and generates signals to control other func- tional blocks within the timer section. control word registers i & ii the control word registers are write-only registers. they are used to control the operating modes of the timers. control word register i controls timers 0, 1 and 2, and control word register ii controls timer 3. detailed description of the control word regis- ters will be included in the register set overview section. counter 0, counter 1, counter 2, counter 3 counters 0, 1, 2, and 3 are the major parts of timers 0, 1, 2, and 3, respectively. these four functional blocks are identical in operation, so only a single counter will be described. the internal block dia- gram of one counter is shown in figure 44. the four counters share a common clock input (clkin), but otherwise are fully independent. each counter is programmable to operate in a different mode. although the control word register is shown in the figure 44, it is not part of the counter itself. its pro- grammed contents are used to control the opera- tions of the counters. 271070 69 figure 44. internal block diagram of a counter 72
M82380 the status register, when latched, contains the cur- rent contents of the control word register and status of the output and null count flag (see read back command). the counting element (ce) is the actual counter. it is a 16-bit presettable synchronous down counter. the output latches (ol) contain two 8-bit latches (olm and oll). normally, these latches `follow' the content of the ce. olm contains the most signifi- cant byte of the counter and oll contains the least significant byte. if the counter latch command is sent to the counter, ol will latch the present count until read by the i386 processor and then return to follow the ce. one latch at a time is enabled by the timer's control logic to drive the internal bus. this is how the 16-bit counter communicates over the 8-bit internal bus. note that ce cannot be read. whenev- er the count is read, it is one of the ol's that is being read. when a new count is written into the counter, the value will be stored in the count registers (cr), and transferred to ce. the transferring of the contents from cr's to ce is defined as `loading' of the coun- ter. the count register contains two 8-bit registers: crm (which contains the most significant byte) and crl (which contains the least significant byte). simi- lar to the ol's, the control logic allows one register at a time to be loaded from the 8-bit internal bus. however, both bytes are transferred from the cr's to the ce simultaneously. both cr's are cleared when the counter is programmed. this way, if the counter has been programmed for one byte count (either the most significant or the least significant byte only), the other byte will be zero. note that ce cannot be written into directly. whenever a count is written, it is the cr that is being written. as shown in the diagram, the control logic consists of three signals: clkin, gate, and out. clkin and gate will be discussed in detail in the section that follows. out is the internal output of the coun- ter. the external outputs of some timers (tout) are the inverted version of out (see tout1, tout2 , tout3 ). the state of out depends on the mode of operation of the timer. 5.2 interface signals 5.2.1 clkin clkin is an input signal used by all four timers for internal timing reference. this signal can be inde- pendent of the M82380 system clock, clk2. in the following discussion, each `clk pulse' is defined as the time period between a rising edge and a falling edge, in that order, of clkin. during the rising edge of clkin, the state of gate is sampled. all new counts are loaded and counters are decremented on the falling edge of clkin. please note that there are no restrictions on the clkin signal during write cycles to the M82380 timer unit. refer to appendix d for details on this issue. 5.2.2 tout1, tout2 , tout3 tout1, tout2 and tout3 are the external output signals of timer 1, timer 2 and timer 3, respective- ly. tout2 and tout3 are the inverted signals of their respective counter outputs, out. there is no external output for timer 0. if timer 2 is to be used as a tone generator of a speaker, external buffering must be used to provide sufficient drive capability. the outputs of timer 2 and 3 are dual function pins. the output pin of timer 2 (tout2 /irq3 ), which is a bidirectional open-collector signal, can also be used as interrupt request input. when the interrupt func- tion is enabled (through the programmable interrupt controller), a low on this input will generate an in- terrupt request 3 (irq3 ) to the M82380 program- mable interrupt controller. this pin has a weak inter- nal pull-up resistor. to use the irq3 function, timer 2 should be programmed so that out2 is low. ad- ditionally, out3 of timer 3 is connected to an edge detector which will generate an interrupt request 0 (irq0) to the M82380 after the rising edge of out3 (see figure 43). 5.2.3 gate gate is not an externally controllable signal. rath- er, it can be software controlled with the internal control port. the state of gate is always sampled on the rising edge of clkin. depending on the mode of operation, gate is used to enable/disable counting or trigger the start of an operation. for timer 0 and 1, gate is always enabled (high). for timer 2 and 3, gate is connected to bit 0 and 6, respectively, of an internal control port (at ad- dress 61h) of the M82380. after a hardware reset, the state of gate of timer 2 and 3 is disabled (low). 73
M82380 5.3 modes of operation each timer can be independently programmed to operate in one of six different modes. timers are programmed by writing a control word into the con- trol word register followed by an initial count (see programming). the following are defined for use in describing the different modes of operation. clk pulseea rising edge, then a falling edge, in that order of clkin. triggerea rising edge of a timer's gate input. timer/counter loadingethe transfer of a count from count register (cr) to count element (ce). 5.3.1 mode 0einterrupt on terminal count mode 0 is typically used for event counting. after the control word is written, out is initially low, and will remain low until the counter reaches zero. out then goes high and remains high until a new count or a new mode 0 control word is written into the counter. in this mode, gate e high enables counting; gate e low disables counting. however, gate has no effect on out. after the control word and initial count are written to a timer, the initial count will be loaded on the next clk pulse. this clk pulse does not decrement the count, so for an initial count of n, out does not go high until n a 1 clk pulses after the initial count is written. if a new count is written to the timer, it will be loaded on the next clk pulse and counting will continue from the new count. if a two-byte count is written, the following happens: 1. writing the first byte disables counting, out is set low immediately (i.e., no clk pulse required). 2. writing the second byte allows the new count to be loaded on the next clk pulse. this allows the counting sequence to be synchroniz- ed by software. again, out does not go high until n a 1 clk pulses after the new count of n is writ- ten. if an initial count is written while gate is low, the counter will be loaded on the next clk pulse. when gate goes high, out will go high n clk pulses later; no clk pulse is needed to load the counter as this has already been done. 5.3.2 mode 1egate retriggerable one-shot in this mode, out will be initially high. out will go low on the clk pulse following a trigger to start the one-shot operation. the out signal will then remain low until the timer reaches zero. at this point, out will stay high until the next trigger comes in. since the state of gate signals of timer 0 and 1 are inter- nally set to high. after writing the control word and initial count, the timer is considered `armed'. a trigger results in load- ing the timer and setting out low on the next clk pulse. therefore, an initial count of n will result in a one-shot pulse width of n clk cycles. note that this one-shot operation is retriggerable; i.e., out will re- main low for n clk pulses after every trigger. the one-shot operation can be repeated without rewrit- ing the same count into the timer. if a new count is written to the timer during a one- shot operation, the current one-shot pulse width will not be affected until the timer is retriggered. this is because loading of the new count to ce will occur only when the one-shot is triggered. 74
M82380 271070 70 notes: the following conventions apply to all mode timing diagrams. 1. counters are programmed for binary (not bcd) counting and for reading/writing least significant byte (lsb) only. 2. the counter is always selected (cs always low). 3. cw stands for ``control word''; cw e 10 means a control word of 10, hex is written to the counter. 4. lsb stands for ``least significant byte'' of count. 5. numbers below diagrams are count values. the lower number is the least significant byte. the upper number is the most significant byte. since the counter is programmed to read/write lsb only, the most significant byte cannot be read. n stands for an undefined count. vertical lines show transitions between count values. figure 43. mode 0 75
M82380 271070 71 figure 44. mode 1 5.3.3 mode 2erate generator this mode is a divide-by-n counter. it is typically used to generate a real time clock interrupt. out will initially be high. when the initial count has dec- remented to 1, out goes low for one clk pulse, then out goes high again. then the timer reloads the initial count and the process is repeated. in other words, this mode is periodic since the same se- quence is repeated itself indefinitely. for an initial count of n, the sequence repeats every n clk cy- cles. similar to mode 0, gate e high enables counting, where gate e low disables counting. if gate goes low during an output pulse (low), out is set high immediately. a trigger (rising edge on gate) will reload the timer with the initial count on the next clk pulse. then, out will go low (for one clk pulse) n clk pulses after the new trigger. thus, gate can be used to synchronize the timer. 76
M82380 271070 72 note: a gate transition should not occur one clock prior to terminal count. figure 45. mode 2 after writing a control word and initial count, the timer will be loaded on the next clk pulse. out goes low (for the clk pulse) n clk pulses after the initial count is written. this is another way the timer may be synchronized by software. writing a new count while counting does not affect the current counting sequence because the new count will not be loaded until the end of the current counting cycle. if a trigger is received after writing a new count but before the end of the current period, the timer will be loaded with the new count on the next clk pulse after the trigger, and counting will continue with the new count. 5.3.4 mode 3esquare wave generator mode 3 is typically used for baud rate generation. functionally, this mode is similar to mode 2 except for the duty cycle of out. in this mode, out will be initially high. when half of the initial count has ex- pired, out goes low for the remainder of the count. 77
M82380 the counting sequence will be repeated, thus this mode is also periodic. note that an initial count of n results in a square wave with a period of n clk pulses. the gate input can be used to synchronize the tim- er. gate e high enables counting; gate e low disables counting. if gate goes low while out is low, out is set high immediately (i.e., no clk pulse is required). a trigger reloads the timer with the initial count on the next clk pulse. after writing a control word and initial count, the timer will be loaded on the next clk pulse. this al- lows the timer to be synchronized by software. writing a new count while counting does not affect the current counting sequence. if a trigger is re- ceived after writing a new count but before the end of the current half-cycle of the square wave, the tim- er will be loaded with the new count on the next clk pulse and counting will continue from the new count. otherwise, the new count will be loaded at the end of the current half-cycle. there is a slight difference in operation depending on whether the initial count is even or odd. the following description is to show exactly how this mode is implemented. even counts: out is initially high. the initial count is loaded on one clk pulse and is decremented by two on suc- ceeding clk pulses. when the count expires (decre- mented to 2), out changes to low and the timer is reloaded with the initial count. the above process is repeated indefinitely. odd counts: out is initially high. the initial count minus one (which is an even number) is loaded on one clk 271070 73 note: a-gate transition should not occur one clock prior to terminal count. figure 46. mode 3 78
M82380 pulse and is decremented by two on succeeding clk pulses. one clk pulse after the count expires (decremented to 2), out goes low and the timer is loaded with the initial count minus one again. suc- ceeding clk pulses decrement the count by two. when the count expires, out goes high immedi- ately and the timer is reloaded with the initial count minus one. the above process is repeated indefi- nitely. so for odd counts, out will be high for (n a 1)/2 counts and low for (n b 1)/2 counts. 5.3.5 mode 4einitial count triggered strobe this mode allows a strobe pulse to be generated by writing an initial count to the timer. initially, out will be high. when a new initial count is written into the timer, the counting sequence will begin. when the initial count expires (decremented to 1), out will go low for one clk pulse and then go high again. again, gate e high enables counting while gate e low disables counting. gate has no effect on out. after writing the control word and initial count, the timer will be loaded on the next clk pulse. this clk pulse does not decrement the count, so for an initial count of n, out does not strobe low until n a 1 clk pulses after initial count is written. if a new count is written during counting, it will be loaded in the next clk pulse and counting will con- tinue from the new count. 271070 74 figure 47. mode 4 79
M82380 if a two-byte count is written, the following will occur: 1. writing the first byte has no effect on counting. 2. writing the second byte allows the new count to be loaded on the next clk pulse. out will strobe low n a 1 clk pulses after the new count of n is written. therefore, when the strobe pulse will occur after a trigger depends on the value of the initial count loaded. 5.3.6 mode 5egate retriggerable strobe mode 5 is very similar to mode 4 except the count sequence is triggered by the gate signal instead of by writing an initial count. initially, out will be high. counting is triggered by a rising edge of gate. when the initial count has expired (decremented to 1), out will go low for one clk pulse and then go high again. after loading the control word and initial count, the count element will not be loaded until the clk pulse after a trigger. this clk pulse does not decrement the count. therefore, for an initial count of n, out does not strobe low until n a 1 clk pulses after a trigger. 271070 75 figure 48. mode 5 80
M82380 summary of gate operations mode gate low or gate rising gate going low high 0 disable count no effect enable count 1 no effect 1. initiate count no effect 2. reset output after next clock 2 1. disable count initiate count enable count 2. sets output high immediately 3 1. disable count initiate count enable count 2. sets output high immediately 4 disable count no effect enable count 5 no effect initiate count no effect the counting sequence is retriggerable. every trig- ger will result in the timer being loaded with the initial count on the next clk pulse. if the new count is written during counting, the cur- rent counting sequence will not be affected. if a trig- ger occurs after the new count is written but before the current count expires, the timer will be loaded with the new count on the next clk pulse and a new count sequence will start from there. 5.3.7 operation common to all modes gate the gate input is always sampled on the rising edge of clkin. in modes 0, 2, 3 and 4, the gate input is level sensitive. the logic level is sampled on the rising edge of clkin. in modes 1, 2, 3 and 5, the gate input is rising edge sensitive. in these modes, a rising edge of gate (trigger) sets an edge sensi- tive flip-flop in the timer. the flip-flop is reset imme- diately after it is sampled. this way, a trigger will be detected no matter when it occurs; i.e., a high logic level does not have to be maintained until the next rising edge of clkin. note that in modes 2 and 3, the gate input is both edge and level sensitive. counter new counts are loaded and counters are decre- mented on the falling edge of clkin. the largest possible initial count is 0. this is equivalent to 2 ** 16 for binary counting and 10 ** 4 for bcd counting. note that the counter does not stop when it reaches zero. in modes 0, 1, 4, and 5, the counter `wraps around' to the highest count: either ffff hex for binary counting or 9999 for bcd counting, and con- tinues counting. modes 2 and 3 are periodic. the counter reloads itself with the initial count and con- tinues counting from there. the minimum and maximum initial count in each counter depends on the mode of operation. they are summarized below. mode min max 010 110 220 320 410 510 5.4 register set overview the programmable interval timer module of the M82380 contains a set of six registers. the port ad- dress map of these registers is shown in table 13. table 13. timer register port address map port address description 40h counter 0 register (read/write) 41h counter 1 register (read/write) 42h counter 2 register (read/write) 43h control word register i (counter 0 ,1&2) (write-only) 44h counter 3 register (read/write) 45h reserved 46h reserved 47h control word register ii (counter 3) (write-only) 81
M82380 5.4.1 counter 0, 1, 2, 3 registers these four 8-bit registers are functionally identical. they are used to write the initial count value into the respective timer. also, they can be used to read the latched count value of a timer. since they are 8-bit registers, reading and writing of the 16-bit initial count must follow the count format specified in the control word registers; i.e., least significant byte only, most significant byte only, or least significant byte then most significant byte (see programming). 5.4.2 control word registe ri&ii there are two control word registers associated with the timer section. one of the two registers (control word register i) is used to control the oper- ations of counters 0, 1, and 2 and the other (control word register ii) is for counter 3. the major func- tions of both control word registers are listed be- low: e select the timer to be programmed. e define which mode the selected timer is to oper- ate in. e define the count sequence; i.e., if the selected timer is to count as a binary counter or a binary coded decimal (bcd) counter. e select the byte access sequence during timer read/write operations; i.e., least significant byte only, most significant byte only, or least signifi- cant byte first, then most significant byte. also, the control word registers can be pro- grammed to perform a counter latch command or a read back command which will be described later. 5.5 programming 5.5.1 initialization upon power-up or reset, the state of all timers is undefined. the mode, count value, and output of all timers are random. from this point on, how each timer operates is determined solely by how it is pro- grammed. each timer must be programmed before it can be used. since the outputs of some timers can generate interrupt signals to the M82380, all timers should be initialized to a known state. timers are programmed by writing a control word into their respective control word registers. then, an initial count can be written into the correspond- ing count register. in general, the programming pro- cedure is very flexible. only two conventions need to be remembered: 1. for each timer, the control word must be written before the initial count is written. 2. the 16-bit initial count must follow the count for- mat specified in the control word (least signifi- cant byte only, most significant byte only, or least significant byte first, followed by most significant byte). since the two control word registers and the four counter registers have separate addresses, and each timer can be individually selected by the appro- priate control word register, no special instruction sequence is required. any programming sequence that follows the conventions above is acceptable. a new initial count may be written to a timer at any time without affecting the timer's programmed mode in any way. count sequence will be affected as de- scribed in the modes of operation section. note that the new count must follow the programmed count format. if a timer is previously programmed to read/write two-byte counts, the following precaution applies. a program must not transfer control between writing the first and second byte to another routine which also writes into the same timer. otherwise, the read/write will result in incorrect count. whenever a control word is written to a timer, all control logic for that timer(s) is immediately reset (i.e., no clk pulse is required). also, the corre- sponding output pin, tout ), goes to a known initial state. 5.5.2 read operation three methods are available to read the current count as well as the status of each timer. they are: read counter registers, counter latch command and read back command. following is a descrip- tion of these methods. read counter registers the current count of a timer can be read by perform- ing a read operation on the corresponding counter register. the only restriction of this read operation is that the clkin of the timers must be inhibited by 82
M82380 using external logic. otherwise, the count may be in the process of changing when it is read, giving an undefined result. note that since all four timers are sharing the same clkin signal, inhibiting clkin to read a timer will unavoidably disable the other timers also. this may prove to be impractical. therefore, it is suggested that either the counter latch com- mand or the read back command be used to read the current count of a timer. another alternative is to temporarily disable a timer before reading its counter register by using the gate input. depending on the mode of operation, gate e low will disable the counting operation. however, this option is available on timer 2 and 3 only, since the gate signals of the other two timers are internally enabled all the time. counter latch command a counter latch command will be executed when- ever a special control word is written into a control word register. two bits written into the control word register distinguish this command from a `reg- ular' control word (see register bit definition). also, two other bits in the control word will select which counter is to be latched. upon execution of this command, the selected counter's output latch (ol) latches the count at the time the counter latch command is received. this count is held in the latch until it is read by the m80386, or until the timer is reprogrammed. the count is then unlatched automatically and the ol returns to `following' the counting element (ce). this allows reading the contents of the counters `on the fly' without affecting counting in progress. multi- ple counter latch commands may be used to latch more than one counter. each latched count is held until it is read. counter latch commands do not af- fect the programmed mode of the timer in any way. if a counter is latched, and at some time later, it is latched again before the prior latched count is read, the second counter latch command is ignored. the count read will then be the count at the time the first command was issued. in any event, the latched count must be read ac- cording to the programmed format. specifically, if the timer is programmed for two-byte counts, two bytes must be read. however, the two bytes do not have to be read right after the other. read/write or programming operations of other timers may be per- formed between them. another feature of this counter latch command is that read and write operations of the same timer may be interleaved. for example, if the timer is pro- grammed for two-byte counts, the following se- quence is valid. 1. read least significant byte. 2. write new least significant byte. 3. read most significant byte. 4. write new most significant byte. if a timer is programmed to read/write two-byte counts, the following precaution applies. a program must not transfer control between reading the first and second byte to another routine which also reads from that same timer. otherwise, an incorrect count will be read. read back command the read back command is another special com- mand word operation which allows the user to read the current count value and/or the status of the se- lected timer(s). like the counter latch command, two bits in the command word identify this as a read back command (see register bit definition). the read back command may be used to latch multiple counter output latches (ol's) by selecting more than one timer within a command word. this single command is functionally equivalent to several counter latch commands, one for each counter to be latched. each counter's latched count will be held until it is read by the m80386 or until the timer is reprogrammed. the counter is automatically un- latched when read, but other counters remain latched until they are read. if multiple read back commands are issued to the same timer without reading the count, all but the first are ignored; i.e., the count read will correspond to the very first read back command issued. as mentioned previously, the read back command may also be used to latch status information of the selected timer(s). when this function is enabled, the status of a timer can be read from the counter reg- ister after the read back command is issued. the status information of a timer includes the following: 1. mode of timer: this allows the user to check the mode of opera- tion of the timer last programmed. 2. state of tout pin of the timer: this allows the user to monitor the counter's out- put pin via software, possibly eliminating some hardware from a system. 83
M82380 3. null count/count available: the null count bit in the status byte indicates if the last count written to the count register (cr) has been loaded into the counting element (ce). the exact time this happens depends on the mode of the timer and is described in the pro- gramming section. until the count is loaded into the counting element (ce), it cannot be read from the timer. if the count is latched or read before this occurs, the count value will not reflect the new count just written. if multiple status latch operations of the timer(s) are performed without reading the status, all but the first command are ignored; i.e., the status read in will correspond to the first read back command issued. both the current count and status of the selected timer(s) may be latched simultaneously by enabling both functions in a single read back command. this is functionally the same as issuing two separate read back commands at once. once again, if multi- ple read commands are issued to latch both the count and status of a timer, all but the first command will be ignored. if both count and status of a timer are latched, the first read operation of that timer will return the latched status, regardless of which was latched first. the next one or two (if two count bytes are to be read) read operations return the latched count. note that subsequent read operations on the counter register will return the unlatched count (like the first read method discussed). 5.6 register bit definitions counter 0, 1, 2, 3 register (read/write) port address description 40h counter 0 register (read/write) 41h counter 1 register (read/write) 42h counter 2 register (read/write) 44h counter 3 register (read/write) 45h reserved 46h reserved 271070 76 84
M82380 note that these 8-bit registers are for writing and reading of one byte of the 16-bit count value, either the most significant or the least significant byte. control word register i & ii (write-only) port address description 43h control word register i (counter 0, 1, 2) (write-only) 47h control word register ii (counter 3) (write-only) control word register i 271070 77 control word register ii 271070 78 counter latch command format (write to control word register) 271070 79 timer gate mode trigger 0 1 2 3 edge level 0 x interrupt on terminal count 1nana jj x gate retriggerable one shot 2 x x rate generator 3 x x square wave generator 4 x initial count triggered strobe 5nana jj x gate retriggerable strobe j e must use port 61 to generate l edge. na e not applicable 85
M82380 read back command format (write to control word register) 271070 80 status format (returned from read back command) 271070 81 6.0 wait state generator 6.1 functional description the M82380 contains a programmable wait state generator which can generate a pre-programmed number of wait states during both cpu and dma initiated bus cycles. this wait state generator is ca- pable of generating 1 to 16 wait states in non-pipe- lined mode, and 0 to 15 wait states in pipelined mode. depending on the bus cycle type and the two wait state control inputs (wsc 0 1), a pre-pro- grammed number of wait states in the selected wait state register will be generated. the wait state generator can also be disabled to allow the use of devices capable of generating their own ready signals. figure 49 is a block diagram of the wait state generator. 86
M82380 6.2 interface signals the following describes the interface signals which affect the operation of the wait state generator. the ready , wsc0 and wsc1 signals are inputs. readyo is the ready output signal to the host proc- essor. 6.2.1 ready ready is an active low input signal which indi- cates to the M82380 the completion of a bus cycle. in the master mode (e.g., M82380 initiated dma transfer), this signal is monitored to determine whether a peripheral or memory needs wait states inserted in the current bus cycle. in the slave mode, it is used (together with the ads signal) to trace cpu bus cycles to determine if the current cycle is pipe- lined. 6.2.2 readyo readyo (ready out) is an active low output sig- nal and is the output of the wait state generator. the number of wait states generated depends on the wsc(0 1) inputs. note that special cases are handled for access to the M82380 internal registers and for the refresh cycles. for M82380 internal reg- ister access, readyo will be delayed to take into account the command recovery time of the register. one or more wait states will be generated in a pipe- lined cycle. during refresh, the number of wait states will be determined by the preprogrammed value in the refresh wait state register. in the simplest configuration, readyo can be con- nected to the ready input of the M82380 and the i386 cpu. this is, however, not always the case. if external circuitry is to control the ready inputs as well, additional logic will be required (see application issues). 6.2.3 wsc(0 1) these two wait state control inputs select one of the three pre-programmed 8-bit wait state registers which determines the number of wait states to be generated. the most significant half of the three wait state registers corresponds to memory ac- cesses, the least significant half to i/o accesses. the combination wsc(0 1) e 11 disables the wait state generator. 271070 82 figure 49. wait state generator block diagram 87
M82380 271070 83 figure 50. wait states in non-pipelined cycles 6.3 bus function 6.3.1 wait states in non-pipelined cycle the timing diagram of two typical non-pipelined cy- cles with M82380 generated wait states is shown in figure 50. in this diagram, it is assumed that the internal registers of the M82380 are not addressed. during the first t2 state of each bus cycle, the wait state control and the m/io inputs are sampled to determine which wait state register (if any) is se- lected. if the wsc inputs are active (i.e., not both are driven high), the pre-programmed number of wait states corresponding to the selected wait state register will be requested. this is done by driving the readyo output high during the end of each t2 state. the wsc(0 1) inputs need only be valid during the very first t2 state of each non-pipelined cycle. as a general rule, the wsc inputs are sampled on the rising edge of the next clock (m82384 clk) after the last state when ads (address status) is asserted. the number of wait states generated depends on the type of bus cycle, and the number of wait states requested. the various combinations are discussed below. 1. access the M82380 internal registers: 2 to 5 wait states, depending upon the specific register ad- dressed. some back-to-back sequences to the in- terrupt controller will require 7 wait states. 2. interrupt acknowledge to the M82380: 5 wait states. 3. refresh: as programmed in the refresh wait state register (see register set overview). note that if wsc(0 1) e 11, readyo will stay inac- tive. 4. other bus cycles: depending on wsc(0 1) and m/io inputs, these inputs select a wait state register in which the number of wait states will be equal to the pre-programmed wait state count in the register plus 1. the wait state register selec- tion is defined as follows (table 14). 88
M82380 table 14. wait state register selection m/io y wsc(1 0) register selected 0 00 wait reg 0 (i/o half) 0 01 wait reg 1 (i/o half) 0 10 wait reg 2 (i/o half) 1 00 wait reg 0 (mem half) 1 01 wait reg 1 (mem half) 1 10 wait reg 2 (mem half) x 11 wait state gen. disabled the wait state control signals, wsc(0 1), can be generated with the address decode and the read/ write control signals as shown in figure 51. 271070 84 figure 51. wsc(0 1) generation note that during halt and shutdown, the num- ber of wait states will depend on the wsc(0 1) in- puts, which will select the memory half of one of the wait state registers (see cpu reset and shutdown detect). 6.3.2 wait states in pipelined cycle the timing diagram of two typical pipelined cycles with M82380 generated wait states is shown in fig- ure 52. again, in this diagram, it is assumed that the M82380 internal registers are not addressed. as de- fined in the timing of the i386 processor, the ad- dress (a 2 31), byte enable (be 0 3), and other control signals (m/io , ads ) are asserted one t state earlier than in a non-pipelined cycle; i.e., they are asserted at t2p. similar to the non-pipelined case, the wait state control (wsc) inputs are sam- pled in the middle of the state after the last state when the ads signal is asserted. therefore, the wsc inputs should be asserted during the t1p state of each pipelined cycle (which is one t state earlier than in the non-pipelined cycle). 271070 85 figure 52. wait state in pipelined cycles 89
M82380 the number of wait states generated in a pipelined cycle is selected in a similar manner as in the non- pipelined case discussed in the previous section. the only difference here is that the actual number of wait states generated will be one less than that of the non-pipelined cycle. this is done automatically by the wait state generator. 6.3.3 extending and early terminating bus cycle the M82380 allows external logic to either add wait states or cause early termination of a bus cycle by controlling the ready input to the M82380 and the host processor. a possible configuration is shown in figure 53. the external ready signal of figure 53 allows external devices to cause early termination of a bus cycle. when this signal is asserted low, the output of the circuit will also go low (even though the readyo of the M82380 may still be high). this output is fed to the ready input of the m80386 and the M82380 to indicate the completion of the current bus cycle. similarly, the ext. not ready (external not ready) signal is used to delay the ready input of the processor and the M82380. as long as this sig- nal is driven high, the output of the circuit will drive the ready input high. this will effectively extend the duration of a bus cycle. however, it is important to note that if the two-level logic is not fast enough to satisfy the ready setup time, the or gate should be eliminated. instead, the M82380 wait state gen- erator can be disabled by driving both wsc(0 1) high. in this case, the addressed memory or i/o device should activate the external ready input whenever it is ready to terminate the current bus cycle. figure 54 and 55 show the timing relationships of the ready signals for the early termination and exten- sion of the bus cycles. the application issues sec- tion of this data sheet contains a detailed timing analysis of the external circuit. 271070 86 figure 53. external `ready' control logic 271070 87 figure 54. early termination of bus cycle by `ready ' 90
M82380 271070 88 figure 55. extending bus cycle by `ready ' due to the following implications, it should be noted that early termination of bus cycles in which M82380 internal registers are accessed is not recommended. 1. erroneous data may be read from or written into the addressed register. 2. the M82380 must be allowed to recover either before hlda (hold acknowledge) is asserted or before another bus cycle into an M82380 internal register is initiated. the recovery time, in bus periods, equals the re- maining wait states that were avoided plus 4. 6.4 register set overview altogether, there are four 8-bit internal registers as- sociated with the wait state generator. the port ad- dress map of these registers is shown below in ta- ble 15. a detailed description of each follows. table 15. register address map port address description 72h wait state reg 0 (read/write) 73h wait state reg 1 (read/write) 74h wait state reg 2 (read/write) 75h ref. wait state reg (read/write) wait state register 0, 1, 2 these three 8-bit read/write registers are functional- ly identical. they are used to store the pre-pro- grammed wait state count. one half of each register contains the wait state count for i/o accesses while the other half contains the count for memory ac- cesses. the total number of wait states generated will depend on the type of bus cycle. for a non-pipe- lined cycle, the actual number of wait states request- ed is equal to the wait state count plus 1. for a pipelined cycle, the number of wait states will be equal to the wait state count in the selected register. therefore, the wait state generator is capable of generating 1 to 16 wait states in non-pipelined mode, and 0 to 15 wait states in pipelined mode. note that the minimum wait state count in each reg- ister is 0. this is equivalent to 0 wait states for a pipelined cycle and 1 wait state for a non-pipelined cycle. refresh wait state register similar to the wait state registers discussed above, this 4-bit register is used to store the number of wait states to be generated during the dram refresh cy- cle. note that the refresh wait state register is not selected by the wsc inputs. it will automatically be 91
M82380 chosen whenever a dram refresh cycle occurs. if the wait state generator is disabled during the re- fresh cycle (wsc(0 1) e 11), readyo will stay inactive and the refresh wait state register is ig- nored. 6.5 programming using the wait state generator is relatively straight- forward. no special programming sequence is re- quired. in order to ensure the expected number of wait states will be generated when a register is se- lected, the registers to be used must be pro- grammed after power-up by writing the appropriate wait state count into each register. note that upon hardware reset, all wait state registers are initial- ized with the value ffh, giving the maximum num- ber of wait states possible. also, each register can be read to check the wait state count previously stored in the register. 6.6 register bit definition wait state register 0, 1, 2 port address description 72h wait state register 0 (read/write) 73h wait state register 1 (read/write) 74h wait state register 2 (read/write) 271070 89 refresh wait state register port address: 75h (read/write) 271070 90 6.7 application issues 6.7.1 external `ready' control logic as mentioned previously, wait state cycles generat- ed by the M82380 can be terminated early or ex- tended longer by means of additional external logic (see figure 53). in order to ensure that the ready input timing requirement of the i386 processor and the M82380 is satisfied, special care must be taken when designing this external control logic. this sec- tion addresses the design requirements. 92
M82380 a simplified block diagram of the external logic along with the ready timing diagram is shown in figure 56. the purpose is to determine the maximum delay time allowed in the external control logic in order to satisfy the ready setup time. first, it will be assumed that the i386 processor is running at 16 mhz (i.e., clk2 and 32 mhz). there- fore, one bus state (two clk2 periods) will be equiv- alent to 62.5 nsec. according to the ac specifica- tions of the M82380, the maximum delay time for valid readyo signal is 31 ns after the rising edge of clk2 in the beginning of t2 (for non-pipelined cycle) or t2p (for pipelined cycle). also, the minimum ready setup time of the i386 processor and the M82380 should be 20 ns before the rising edge of clk2 at the beginning of the next bus state. this limits the total delay time for the external ready control logic to be 11 ns (62.5 b 31 b 21) in order to meet the ready setup timing requirement. 271070 91 a e phi1 a phi2 e 62.5 ns b e maximum readyo valid delay e 31 ns c e ready setup time e 21 ns d e maximum ready control logic delay e a b b b c e 11 ns figure 56. `ready' timing consideration 93
M82380 7.0 dram refresh controller 7.1 functional description the M82380 dram refresh controller consists of a 24-bit refresh address counter and refresh re- quest logic for dram refresh operations (see figure 57). timer 1 can be used as a trigger signal to the dram refresh request logic. the refresh bus size can be programmed to be 8-, 16-, or 32-bit wide. depending on the refresh bus size, the refresh address counter will be incremented with the appro- priate value after every refresh cycle. the internal logic of the M82380 will give the refresh operation the highest priority in the bus control arbitration pro- cess. bus control is not released and re-requested if the M82380 is already a bus master. 7.2 interface signals 7.2.1 tout1/ref the dual function output pin of timer 1 (tout1/ ref ) can be programmed to generate dram re- fresh signal. if this feature is enabled, the rising edge of timer 1 output (tout1) will trigger the dram refresh request logic. after some delay for gaining access of the bus, the M82380 dram controller will generate a dram refresh signal by driving ref output low. this signal is cleared after the refresh cycle has taken place, or by a hardware reset. if the dram refresh feature is disabled, the tout1/ref output pin is simply the timer 1 out- put. detailed information of how timer 1 operates is discussed in section 6eprogrammable interval timer, and will not be repeated here. 271070 92 figure 57. dram refresh controller 94
M82380 7.3 bus function 7.3.1 arbitration in order to ensure data integrity of the drams, the M82380 gives the dram refresh signal the highest priority in the arbitration logic. it allows dram re- fresh to interrupt a dma in progress in order to per- form the dram refresh cycle. the dma service will be resumed after the refresh is done. in case of a dram refresh during a dma process, the cascaded device will be requested to get off the bus. this is done by deasserting the edack signal. once dreqn goes inactive, the M82380 will per- form the refresh operation. note that the dma con- troller does not completely relinquish the system bus during refresh. the refresh generator simply `steals' a bus cycle between dma accesses. figure 58 shows the timing diagram of a refresh cycle. upon expiration of timer 1, the M82380 will try to take control of the system bus by asserting hold. as soon as the M82380 see hlda go active, the dram refresh cycle will be carried out by acti- vating the ref signal as well as the refresh address and control signals on the system bus (note that ref will not be active until two clk periods after hlda is asserted). the address bus will contain the 24-bit address currently in the refresh address counter. the control signals are driven the same way as in a memory read cycle. this `read' opera- tion is complete when the ready signal is driven low. then, the M82380 will relinquish the bus by de-asserting hold. typically, a refresh cycle with- out wait states will take five bus states to execute. if `n' wait states are added, the refresh cycle will last for five plus `n' bus states. how often the refresh generation will initiate a re- fresh cycle depends on the frequency of clkin as well as timer1's programmed mode of operation. for this specific application, timer1 should be pro- grammed to operate in mode 2 or 3 to generate a constant clock rate. see the section titled program- mable interval timer for more information on pro- gramming the timer. one dram refresh cycle will be generated each time timer 1 expires (when tout1 changes to low to high). the wait state generator can be used to insert wait states during a refresh cycle. the M82380 will auto- matically insert the desired number of wait states as programmed in the refresh wait state register (see wait state generator). 7.4 modes of operation 7.4.1 word size and refresh address counter the M82380 supports 8-, 16- and 32-bit refresh cy- cle. the bus width during a refresh cycle is program- mable (see programming). the bus size can be pro- grammed via the refresh control register (see reg- ister overview). if the dram bus size is 8-, 16-, or 271070 93 * note: a24 a31 e 1 during refresh cycle. figure 58. M82380 refresh cycle 95
M82380 32-bits, the refresh address counter will be incre- mented by 1, 2, or 4, respectively. the refresh address counter is cleared by a hard- ware reset. 7.5 register set overview the refresh generator has two internal registers to control its operation. they are the refresh control register and the refresh wait state register. their port address map is shown in table 16 below. table 16. register address map port address description 1ch refresh control reg. (read/write) 75h ref. wait state reg. (read/write) the refresh wait state register is not part of the refresh generator. it is only used to program the number of wait states to be inserted during a refresh cycle. this register is discussed in detail in section 7 (wait state generator) and will not be repeated here. refresh control register this 2-bit register serves two functions. first, it is used to enable/disable the dram refresh function output. if disabled, the output of timer 1 is simply used as a general purpose timer. the second func- tion of this register is to program the dram bus size for the refresh operation. the programmed bus size also determines how the refresh address counter will be incremented after each refresh operation. 7.6 programming upon hardware reset, the dram refresh function is disabled (the refresh control register is cleared). the following programming steps are needed before the refresh generator can be used. since the rate of refresh cycles depends on how timer 1 is pro- grammed, this timer must be initialized with the de- sired mode of operation as well as the correct re- fresh interval (see programming interval timer). whether or not wait states are to be generated dur- ing a refresh cycle, the refresh wait state register must also be programmed with the appropriate val- ue. then, the dram refresh feature must be en- abled and the dram bus width should be defined. these can be done in one step by writing the appro- priate control word into the refresh control register (see register bit definition). after these steps are done, the refresh operation will automatically be in- voked by the refresh generator upon expiration of timer 1. in addition to the above programming steps, it should be noted that after reset, although the tout1/ref becomes the timer 1 output, the state of this pin is undefined. this is because the timer module has not been initialized yet. therefore, if this output is used as a dram refresh signal, this pin should be disqualified by external logic until the re- fresh function is enabled. one simple solution is to logically and this output with hlda, since hlda should not be active after reset. 7.7 register bit definition refresh control register port address: 1ch (read/write) 271070 94 8.0 relocation register and address decode 8.1 relocation register all the integrated peripheral devices in the M82380 are controlled by a set of internal registers. these registers span a total of 256 consecutive address locations (although not all the 256 locations are used). the M82380 provides a relocation register which allows the user to map this set of internal reg- isters into either the memory or i/o address space. the function of the relocation register is to define the base address of the internal register set of the M82380 as well as if the registers are to be memory- or i/o-mapped. the format of the relocation regis- ter is depicted in figure 59. 271070 95 figure 59. relocation register 96
M82380 note that the relocation register is part of the inter- nal register set of the M82380. it has a port address of 7fh. therefore, any time the content of the relo- cation register is changed, the physical location of this register will also be moved. upon reset of the M82380, the content of the relocation register will be cleared. this implies that the M82380 will re- spond to its i/o addresses in the range of 0000h to 00ffh. 8.1.1 i/o-mapped M82380 as shown in figure 59, bit 0 of the relocation regis- ter determines whether the M82380 registers are to be memory-mapped or i/o-mapped. when bit 0 is set to `0', the M82380 will respond to i/o address- es. address signals be0 be3 , a2 a7 will be used to select one of the internal registers to be ac- cessed. bit 1 to bit 7 of the relocation register will correspond to a9 to a15 of the address bus, respec- tively. together with a8 implied to be `0', a15 to a8 will be fully decoded by the M82380. the following shows how the M82380 is mapped into the i/o ad- dress space. example relocation register e 11001110 (0ceh) M82380 will respond to i/o address range from 0ce00h to 0ceffh. therefore, this i/o mapping mechanism allows the M82380 internal registers to be located on any even, contiguous, 256 byte boundary of the system i/o space. port address: 7fh (read/write) 8.1.2 memory-mapped M82380 when bit 0 of the relocation register is set to `1', the M82380 will respond to memory addresses. again, address signals be0 be3 , a2 a7 will be used to select one of the internal registers to be accessed. bit 1 to bit 7 of the relocation register will correspond to a25 a31, respectively. a24 is as- sumed to be `0', and a8 a23 are ignored. consider the following example. example relocation register e 10100111 (0a7h) the M82380 will respond to memory addresses in the range of 0a6xxxx00h to 0a6xxxxffh (where `x' is don't care). this scheme implies that the internal register can be located in any even, contiguous, 2 ** 24 byte page of the memory space. 8.2 address decoding as mentioned previously, the M82380 internal regis- ters do not occupy the entire contiguous 256 ad- dress locations. some of the locations are `unoccu- pied'. the M82380 always decodes the lower 8 ad- dress bits (a0 a7) to determine if any one of its registers is being accessed. if the address does not correspond to any of its registers, the M82380 will not respond. this allows external devices to be lo- cated within the `holes' in the M82380 address space. note that there are several unused address- es reserved for future intel peripheral devices. 9.0 cpu reset and shutdown detect the M82380 will activate the cpurst signal to re- set the host processor when one of the following conditions occurs: e M82380 reset is active; e M82380 detects a i386 processor shutdown cy- cle (this feature can be disabled); e cpurst software command is issued to i386 processor. whenever the cpurst signal is activated, the M82380 will reset its own internal slave-bus state machine. 9.1 hardware reset following a hardware reset, the M82380 will assert its cpurst output to reset the host processor. this output will stay active for as long as the reset input is active. during a hardware reset, the M82380 inter- nal registers will be initialized as defined in the corre- sponding functional descriptions. 9.2 software reset cpurst can be generated by writing the following bit pattern into M82380 register location 64h. d7 d0 1111xxx0 x e don't care 97
M82380 the write operation into this port is considered as an M82380 access and the internal wait state gen- erator will automatically determine the required num- ber of wait states. the cpurst will be active follow- ing the completion of the write cycle to this port. this signal will last for 62 clk2 periods. the M82380 should not be accessed until the cpurst is deactivated. this internal port is write-only and the M82380 will not respond to a read operation to this location. also, during a cpu software reset command, the M82380 will reset its slave-bus state machine. how- ever, its internal registers remain unchanged. this allows the operating system to distinguish a `warm' reset by reading any M82380 internal register previ- ously programmed for an non-default value. the di- agnostic registers can be used or this purpose (see internal control and diagnostic ports). 9.3 shutdown detect the M82380 is constantly monitoring the bus cycle definition signals (m/io , d/c , r/w ) and is able to detect when the i386 processor executes a shut- down bus cycle. upon detection of a processor shut- down, the M82380 will activate the cpurst output for 62 clk2 periods to reset the host processor. this signal is generated after the shutdown cycle is terminated by the ready signal. although the M82380 wait state generator will not automatically respond to a shutdown (or halt) cycle, the wait state control inputs (wsc0, wsc1) can be used to determine the number of wait states in the same manner as other non-M82380 bus cycle. this shutdown detect feature can be enabled or dis- abled by writing a control bit in the internal control port at address 61h (see internal control and diag- nostic ports). this feature is disabled upon a hard- ware reset of the M82380. as in the case of soft- ware reset, the M82380 will reset its slave-bus state machine but will not change any of its internal register contents. 10.0 internal control and diagnostic ports 10.1 internal control port the format of the internal control port of the M82380 is shown in figure 60. this control port is used to enable/disable the processor shutdown de- tect mechanism as well as controlling the gate in- puts of the timer 2 and 3. note that this is a write- only port. therefore, the M82380 will not respond to a read operation to this port. upon hardware reset, this port will be cleared; i.e., the shutdown detect feature and the gate inputs of timer 2 and 3 are disabled. 10.2 diagnostic ports two 8-bit read/write diagnostic ports are provided in the M82380. these are two storage registers and have no effect on the operation of the M82380. they can be used to store checkpoint data or error codes in the power-on sequence and in the diagnostic service routines. as mentioned in cpu reset and shutdown detect section, these diagnostic ports can be used to distinguish between `cold' and `warm' reset. upon hardware reset, both diagnostic ports are cleared. the address map of these diag- nostic ports is shown in figure 61. port address diagnostic port 1 (read/write) 80h diagnostic port 2 (read/write) 88h figure 61. address map of diagnostic ports port address: 61h (write only) 271070 96 figure 60. internal control port 98
M82380 11.0 intel reserved i/o ports there are eleven i/o ports in the M82380 address space which are reserved for intel future peripheral device use only. their address locations are: 2ah, 3dh, 3eh, 45h, 46h, 76h, 77h, 7dh, 7eh, cch and cdh. these addresses should not be used in the system since the M82380 may respond to read/ write operations to these locations and bus conten- tion may occur if any peripheral is assigned to the same address location. 271070 97 figure 62. M82380 pga pinouteview from top side 99
M82380 12.0 mechanical data 12.1 pin assignment the M82380 pinout as viewed from the top side of the pga component is shown in figure 62. its pinout as viewed from the pin side of the component is shown in figure 63. the M82380 pinout as viewed from the topside of the quad flat pack component is shown in figure 64. v cc and gnd connections must be made to multi- ple v cc and v ss (gnd) pins. each v cc and v ss must be connected to the appropriate voltage lev- el. the circuit board should include v cc and gnd planes for power distribution and all v cc pins must be connected to the appropriate plane. table 17 shows the pin assignments for the pga component while table 18 shows the pin assign- ments for the quad flat pack. 271070 98 figure 63. M82380 pga pinouteview from pin side 100
M82380 table 17. M82380 pga pinoutefunctional grouping pin signal a7 a31 c7 a30 b7 a29 a6 a28 b6 a27 c6 a26 a5 a25 b5 a24 c5 a23 b4 a22 b3 a21 c4 a20 b2 a19 c3 a18 c2 a17 d3 a16 d2 a15 e3 a14 e2 a13 e1 a12 f3 a11 f2 a10 f1 a9 g1 a8 g2 a7 g3 a6 h1 a5 h2 a4 j1 a3 h3 a2 j2 be3 j3 be2 k1 be1 l1 be0 pin signal a8 d31 b9 d30 a11 d29 c11 d28 d12 d27 e13 d26 f14 d25 j13 d24 b8 d23 c9 d22 b11 d21 b13 d20 d13 d19 e14 d18 g12 d17 h13 d16 c8 d15 a10 d14 c10 d13 c12 d12 d14 d11 f12 d10 g13 d9 k14 d8 a9 d7 b10 d6 b12 d5 c13 d4 e12 d3 f13 d2 h14 d1 j14 d0 n12 reset m12 cpurst pin signal p12 v cc m14 v cc p1 v cc p2 v cc p14 v cc d1 v cc c14 v cc b1 v cc a2 v cc a4 v cc a12 v cc a14 v cc g14 clk2 l12 d/c k12 w/r l13 m/io k2 ads n4 na j12 hold m3 hlda m6 dreq0 p5 dreq1 n5 dreq2 p4 dreq3 m5 dreq4/irq9 p3 dreq5 m4 dreq6 n3 dreq7 k3 eop l3 edack0 m1 edack1 l2 edack2 pin signal l14 v ss a1 v ss p13 v ss n1 v ss n2 v ss c1 v ss a3 v ss b14 v ss a13 v ss n14 v ss p6 irq23 n6 irq22 m7 irq21 n7 irq20 p7 irq19 p8 irq18 m8 irq17 n8 irq16 p9 irq15 n9 irq14 m9 irq13 n10 irq12 p10 irq11 m2 int n11 clkin k13 tout1/ref n13 tout2 /irq3 m13 tout3 m11 ready h12 readyo p11 wsc0 m10 wsc1 101
M82380 12.2 package dimensions and mounting the M82380 package is in a 132-pin ceramic pin grid array (pga) (figures 62 and 63) and 164-lead cqfp (figure 64). the pins are arranged 0.100 inch (2.54 mm) center-to-center, in a 14 x 14 matrix, three rows around. a wide variety of available sockets allow low inser- tion force or zero insertion force mountings, and a choice of terminals such as soldertail, surface mount, or wire wrap. 271070 b5 (staggered pin arrangement is shown for clarity only. actual package has pins of equal length.) figure 64. m8238 164-lead cqfp pinout (view from top side) 102
M82380 table 18. M82380 cqfp pin cross-reference pin signal 1a4 2v cc 3v ss 4a5 5a6 6a7 7a8 8a9 9v cc 10 v ss 11 a10 12 a11 13 a12 14 a13 15 v cc 16 v ss 17 a14 18 a15 19 a16 20 a17 21 nc 22 nc 23 v cc 24 a18 25 a19 26 a20 27 a21 28 a22 29 v ss 30 v cc 31 a23 32 a24 33 a25 34 a26 35 a27 36 a28 37 a29 38 a30 39 a31 40 v cc 41 d31 pin signal 42 d23 43 d15 44 d7 45 d30 46 v ss 47 v cc 48 d22 49 d14 50 d6 51 v ss 52 v cc 53 d29 54 d21 55 d13 56 d5 57 d28 58 d20 59 d12 60 v cc 61 v ss 62 nc 63 nc 64 v cc 65 d4 66 d27 67 d19 68 d11 69 d3 70 d26 71 d18 72 d10 73 d2 74 v ss 75 v cc 76 d25 77 d17 78 d9 79 v ss 80 clk2 81 v ss 82 d1 pin signal 83 d24 84 d16 85 d8 86 d0 87 v ss 88 v cc 89 readyo 90 tout1/ref 91 hold 92 m/io 93 v ss 94 v cc 95 nc 96 nc 97 w/r 98 d/c 99 tout3 100 tout2 /irq3 101 cpurst 102 nc 103 v cc 104 v ss 105 v cc 106 nc 107 v ss 108 v cc 109 ready 110 reset 111 wsc1 112 wsc0 113 v ss 114 clkin 115 v cc 116 irq11 117 irq12 118 irq13 119 irq14 120 irq15 121 irq16 122 irq17 123 irq18 pin signal 124 irq19 125 irq20 126 irq21 127 irq22 128 irq23 129 v cc 130 v ss 131 dreq0 132 dreq1 133 dreq2 134 dreq3 135 dreq4/irq9 136 dreq5 137 na 138 dreq6 139 dreq7 140 v cc 141 v ss 142 nc 143 nc 144 nc 145 nc 146 hlda 147 int 148 nc 149 nc 150 edacu0 151 edacu1 152 edacu2 153 v cc 154 v ss 155 eop 156 ads 157 be0 158 be1 159 be2 160 be3 161 v cc 162 v ss 163 a2 164 a3 103
M82380 13.0 electrical data 13.1 power and grounding the large number of output buffers (address, data and control) can cause power surges as multiple output buffers drive new signal levels simultaneous- ly. the 22 v cc and v ss pins of the M82380 each feed separate functional units to minimize switching induced noise effects. all v cc pins of the M82380 must be connected on the circuit board. 13.2 power decoupling liberal decoupling capacitance should be placed close to the M82380. the M82380 driving its 32-bit parallel address and data buses at high frequencies can cause transient power surges when driving large capacitive loads. low inductance capacitors and inter- connects are recommended for the best reliability at high frequencies. low inductance capacitors are available specifically for pin grid array packages. 13.3 unused pin recommendations for reliable operation, always connect unused in- puts to a valid logic level. as is the case with most other cmos processes, a floating input will increase the current consumption of the component and give an indeterminate state to the component. 13.4 ice tm -386 support the M82380 specifications provide sufficient drive capability to support the ice386. on the pins that are generally shared between the i386 processor and the M82380, the additional loading represented by the ice386 was allowed for in the design of the M82380. 104
M82380 13.5 maximum ratings storage temperature b 65 cto a 150 c supply voltage with respect to v ss b 0.5v to a 6.5v voltage on any other pin b 0.5v to v cc a 0.5v note: stress above those listed above may cause perma- nent damage to the device. this is a stress rating only and functional operation at these or any other conditions above those listed in the operational sections of this specification is not implied. exposure to absolute maximum rating conditions for extended periods may affect device reliability. al- though the M82380 contains protective circuitry to reset damage from static electric discharges, always take precautions against high static voltages or elec- tric fields. operating conditions mil-std-883 symbol description min max units t c case temperature (instant on) b 55 a 125 c v cc digital supply voltage 4.75 5.25 v extended temperature symbol description min max units t c case temperature (instant on) b 40 a 110 c v cc digital supply voltage 4.75 5.25 v military temperature only (mto) symbol description min max units t c case temperature (instant on) b 55 a 125 c v cc digital supply voltage 4.75 5.25 v 105
M82380 13.6 dc specifications (over specified operating conditions) symbol parameter min max unit notes v il input low voltage b 0.3 0.8 v v ih input high voltage 2.0 v cc a 0.3 v v ilc clk2 input low voltage b 0.3 0.8 v ihc clk2 input high voltage 2.0 v cc a 0.3 v v ol output low voltage i ol e 4 ma: a2 a31, d0 d31 0.45 v i ol e 5 ma: all others 0.45 v v oh output high voltage i oh e 1 ma: a2 a31, d0 d31 2.4 v i oh eb 0.9 ma: all others 2.4 v i li input leakage current for all inputs except: irq11 irq23 , tout2 /irq3 , eop , dreq4/irq9 g 15 m a0v k v in k v cc i li1 input leakage current for 10 b 300 m a0v k v in k v cc pins: irq11 irq23 , (note 1) @ 16 mhz and 20 mhz tout2 /irq3 , eop , 10 b 325 m a0v k v in k v cc dreq4/irq9 (note 1) @ 25 mhz i lo output leakage current g 15 m a0 k v in k v cc i cc supply current 375 ma clk2 e 32 mhz (note 2) c i capacitance (input/io) 12 pf f c e 1 mhz cclk clk2 capacitance 20 pf f c e 1 mhz notes: 1. these pins have internal pullups on them. 2. i cc is specified with inputs driven to cmos levels. i cc may be higher if driven to ttl levels. 106
M82380 13.7 ac specifications the ac specifications given in the following tables consist of output delays and input setup require- ments. the ac diagram's purpose is to illustrate the clock edges from which the timing parameters are measured. the reader should not infer any other tim- ing relationships from them. for specific information on timing relationships between signals, refer to the appropriate functional section. ac spec measurement is defined in figure 65. in- puts must be driven to the levels shown when ac specifications are measured. M82380 output delays are specified with minimum and maximum limits, which are measured as shown. the minimum M82380 output delay times are hold times for exter- nal circuitry. M82380 input setup and hold times are specified as minimums and define the smallest ac- ceptable sampling window. within the sampling win- dow, a synchronous input signal must be stable for correct M82380 operation. 271070 a6 legend: a f emaximum output delay spec b f eminimum output delay spec c f eminimum input setup spec d f eminimum input hold spec notes: 1. input waveforms have tr s 2.0 ns from 0.8v to 2.0v. 2. under rated loading (120 pf) 386 output tr, tf is typically s 4.0 ns from 0.8v to 2.0v. figure 65. drive levels and measurement points for ac specification 107
M82380 ac specification tables (over specified operating conditions) symbol parameter M82380-16 M82380-20 M82380-25 notes min max min max min max operating frequency 4 mhz 16 mhz 4 mhz 20 mhz 4 mhz 25 mhz half clk2 frequency t1 clk2 period 31 ns 125 ns 25 ns 125 ns 20 ns 125 ns t2a clk2 high time 9 8 7 at 2.0v t2b clk2 high time 5 5 4 at (v cc 0.8)v t3a clk2 low time 9 8 7 at 2.0v t3b clk2 low time 7 6 4 at 0.8v t4 clk2 fall time 8 8 7 (v cc 0.8)v to 0.8v t5 clk2 rise time 8 8 7 0.8v to (v cc 0.8)v a (2 31), be (0 3), edack (0 2) t6 valid delay 4 36 4 30 4 20 c l e 120 pf t7 float delay 4 40 4 32 4 27 (note 1) a (2 31), be (03) t8 setup time 6 6 6 t9 hold time 4 4 4 w/r , m/io , d/c , t10 valid delay 6 33 6 28 4 20 c l e 75 pf t11 float delay 4 35 4 30 4 29 (note 1) t12 setup time 6 6 6 t13 hold time 4 4 4 c l e 75 pf t14 ads valid delay 6 33 6 28 4 19 c l e 75 pf t15 float delay 4 35 4 30 4 29 c l e 75 pf t16 setup time 21 15 12 t17 hold time 4 4 4 slave modee d(0 31) read t18 valid delay 3 46 4 46 4 31 c l e 120 pf t19 float delay 6 35 6 29 6 21 (note 1) slave modee d(0 31) write t20 setup time 31 29 20 t21 hold time 26 26 20 108
M82380 ac specification tables (over specified operating conditions) (continued) symbol parameter M82380-16 M82380-20 M82380-25 notes min max min max min max master modee d(0 31) write t22 valid delay 4 48 4 38 8 27 c l e 120 pf t23 float delay 4 35 4 27 4 19 (note 1) master modee d(0 31) read t24 setup time 11 11 7 t25 hold time 6 6 4 t26 ready setup time 21 12 9 t27 hold time 4 4 4 t28 wsc (0 1) setup 6 6 6 t29 hold 21 21 15 t31 reset setup time 13 12 9 t30 hold time 4 4 4 t32 readyo valid delay 4 31 4 28 3 21 c l e 25 pf t33 cpu reset from clk2 2 18 2 16 2 14 c l e 50 pf t34 hold valid delay 5 33 5 30 4 22 c l e 100 pf t35 hlda setup time 21 17 17 t36 hold time 6 6 4 t37a eop setup time 21 17 13 synch. eop t38a eop hold time 4 4 4 t37b eop setup time 11 11 10 asynch. eop t38b eop hold time 11 11 10 t39 eop valid delay 5 38 5 30 4 21 c l e 100 pf t40 eop float delay 5 40 5 32 4 21 c l e 100 pf t41a dreq setup time 21 19 17 synchronous dreq t42a hold time 4 4 4 t41b dreq setup time 11 11 10 asynchronous dreq t42b hold time 11 11 10 t43 int valid delay 500 500 500 from irq input 15 c l e 75 pf t44 na setup time 11 10 7 t45 hold time 15 15 8 t46 clkin frequency 0 mhz 10 mhz 0 mhz 10 mhz 0 mhz 10 mhz t47 clkin high time 30 30 30 at 2.0v t48 clkin low time 50 50 50 at 0.8v note: 1. float conditions occur when the maximum output current becomes less than ilo in magnitude. float delay is not tested. for testing purposes, the float condition occurs when the dynamic output driven voltage changes with current loads. 109
M82380 ac specification tables (over specified operating conditions) (continued) symbol parameter M82380-16 M82380-20 M82380-25 notes min max min max min max t49 clkin rise time 10 10 10 0.8v to v cc b 0.8v t50 clkin fall time 10 10 10 v cc b 0.8v to 0.8v t51 tout1/ref valid 4 36 4 30 4 20 from clk2, c l e 25 pf t52 tout1/ref valid 3 93 3 93 3 90 from clkin t53 tout2 valid delay 3 93 3 93 3 90 from clkin (falling edge only) t54 tout2 float delay 3 40 3 40 3 37 from clkin t55 tout3 valid delay 3 93 3 93 3 90 from clkin note: 1. float conditions occur when the maximum output current becomes less than ilo in magnitude. float delay is not tested. for testing purposes, the float condition occurs when the dynamic output driven voltage changes with current loads. 271070 a7 figure 66. ac test load 271070 a8 figure 67. clk2 timing all outputs loaded to 120 pf unless otherwise noted. all ac timings are tested at 1.5v threshold, except as noted. 110
M82380 271070 a9 figure 68. input setup and hold timing 271070 b0 figure 69. reset timing 111
M82380 271070 b1 figure 70. address output delays 271070 b2 figure 71. data bus output delays 112
M82380 271070 b3 figure 72. control output delays 271070 b4 figure 73. timer output delays 113

M82380 appendix a ports listed by address port address (hex) description 00 read/write dma channel 0 target address, a0 a15 01 read/write dma channel 0 byte count, b0 b15 02 read/write dma channel 1 target address, a0 a15 03 read/write dma channel 1 byte count, b0 b15 04 read/write dma channel 2 target address, a0 a15 05 read/write dma channel 2 byte count, b0 b15 06 read/write dma channel 3 target address, a0 a15 07 read/write dma channel 3 byte count, b0 b15 08 read/write dma channel 0 3 status/command i register 09 read/write dma channel 0 3 software request register 0a write dma channel 0 3 set-reset mask register 0b write dma channel 0 3 mode register i 0c write clear byte-pointer ff 0d write dma master-clear 0e write dma channel 0 3 clear mask register 0f read/write dma channel 0 3 mask register 10 read/write dma channel 0 target address, a24 a31 11 read/write dma channel 0 byte count, b16 b23 12 read/write dma channel 1 target address, a24 a31 13 read/write dma channel 1 byte count, b16 b23 14 read/write dma channel 2 target address, a24 a31 15 read/write dma channel 2 byte count, b16 b23 16 read/write dma channel 3 target address, a24 a31 17 read/write dma channel 3 byte count, b16 b23 18 write dma channel 0 3 bus size register 19 read/write dma channel 0 3 chaining register 1a write dma channel 0 3 command register ii 1b write dma channel 0 3 mode register ii 1c read/write refresh control register 1e reset software request interrupt 20 write bank b icw1, ocw2, or ocw3 read bank b poll, interrupt request or in-service status register 21 write bank b icw2, icw3, icw4 or ocw1 read bank b interrupt mask register 22 read bank b icw2 28 read/write irq8 vector register 29 read/write irq9 vector register 2a reserved 2b read/write irq11 vector register 2c read/write irq12 vector register 2d read/write irq13 vector register 2e read/write irq14 vector register 2f read/write irq15 vector register a-1
M82380 appendix aeports listed by address (continued) port address (hex) description 30 write bank a icw1, ocw2 or ocw3 read bank a poll, interrupt request or in-service status register 31 write bank a icw2, icw3, icw4 or ocw1 read bank a interrupt mask register 32 read bank a icw2 38 read/write irq0 vector register 39 read/write irq1 vector register 3a read/write irq1.5 vector register 3b read/write irq3 vector register 3c read/write irq4 vector register 3d reserved 3e reserved 3f read/write irq7 vector register 40 read/write counter 0 register 41 read/write counter 1 register 42 read/write counter 2 register 43 write control word register iecounter 0, 1, 2 44 read/write counter 3 register 45 reserved 46 reserved 47 write word register iiecounter 3 61 write internal control port 64 write cpu reset register (data-1111xxx0h) 72 read/write wait state register 0 73 read/write wait state register 1 74 read/write wait state register 2 75 read/write refresh wait state register 76 reserved 77 reserved 7d reserved 7e reserved 7f read/write relocation register 80 read/write internal diagnostic port 0 81 read/write dma channel 2 target address, a16 a23 82 read/write dma channel 3 target address, a16 a23 83 read/write dma channel 1 target address, a16 a23 87 read/write dma channel 0 target address, a16 a23 88 read/write internal diagnostic port 1 89 read/write dma channel 6 target address, a16 a23 8a read/write dma channel 7 target address, a16 a23 8b read/write dma channel 5 target address, a16 a23 8f read/write dma channel 4 target address, a16 a23 a-2
M82380 appendix aeports listed by address (continued) port address (hex) description 90 read/write dma channel 0 requester address, a0 a15 91 read/write dma channel 0 requester address, a16 a31 92 read/write dma channel 1 requester address, a0 a15 93 read/write dma channel 1 requester address, a16 a31 94 read/write dma channel 2 requester address, a0 a15 95 read/write dma channel 2 requester address, a16 a31 96 read/write dma channel 3 requester address, a0 a15 97 read/write dma channel 3 requester address, a16 a31 98 read/write dma channel 4 requester address, a0 a15 99 read/write dma channel 4 requester address, a16 a31 9a read/write dma channel 5 requester address, a0 a15 9b read/write dma channel 5 requester address, a16 a31 9c read/write dma channel 6 requester address, a0 a15 9d read/write dma channel 6 requester address, a16 a31 9e read/write dma channel 7 requester address, a0 a15 9f read/write dma channel 7 requester address, a16 a31 a0 write bank c icw1, ocw2 or ocw3 read bank c poll, interrupt request or in-service status register a1 write bank c icw2, icw3, icw4 or ocw1 read bank c interrupt mask register a2 read bank c icw2 a8 read/write irq16 vector register a9 read/write irq17 vector register aa read/write irq18 vector register ab read/write irq19 vector register ac read/write irq20 vector register ad read/write irq21 vector register ae read/write irq22 vector register af read/write irq23 vector register c0 read/write dma channel 4 target address, a0 a15 c1 read/write dma channel 4 byte count, b0 b15 c2 read/write dma channel 5 target address, a0 a15 c3 read/write dma channel 5 byte count, b0 b15 c4 read/write dma channel 6 target address, a0 a15 c5 read/write dma channel 6 byte count, b0 b15 c6 read/write dma channel 7 target address, a0 a15 c7 read/write dma channel 7 byte count, b0 b15 c8 read dma channel 4 7 status/command i register c9 read/write dma channel 4 7 software request register ca write dma channel 4 7 setereset mask register cb write dma channel 4 7 mode register i cc reserved cd reserved ce write dma channel 4 7 clear mask register cf read/write dma channel 4 7 mask register a-3
M82380 appendix aeports listed by address (continued) port address (hex) description d0 read/write dma channel 4 target address, a24 a31 d1 read/write dma channel 4 byte count, b16 b23 d2 read/write dma channel 5 target address, a24 a31 d3 read/write dma channel 5 byte count, b16 b23 d4 read/write dma channel 6 target address, a24 a31 d5 read/write dma channel 6 byte count, b16 b23 d6 read/write dma channel 7 target address, a24 a31 d7 read/write dma channel 7 byte count, b16 b23 d8 write dma channel 4 7 bus size register d9 read/write dma channel 4 7 chaining register da write dma channel 4 7 command register ii db write dma channel 4 7 mode register ii a-4
M82380 appendix b ports listed by function port address (hex) description dma controller 0d write dma master-clear 0c write dma clear byte-pointer ff 08 read/write dma channel 0 3 status/command i register c8 read/write dma channel 4 7 status/command i register 1a write dma channel 0 3 command register ii da write dma channel 4 7 command register ii 0b write dma channel 0 3 mode register i cb write dma channel 4 7 mode register i 1b write dma channel 0 3 mode register ii db write dma channel 4 7 mode register ii 09 read/write dma channel 0 3 software request register c9 read/write dma channel 4 7 software request register 1e reset software request interrupt 0e write dma channel 0 3 clear mask register ce write dma channel 4 7 clear mask register 0f read/write dma channel 0 3 mask register cf read/write dma channel 4 7 mask register 0a write dma channel 0 3 set-reset mask register ca write dma channel 4 7 set-reset mask register 18 write dma channel 0 3 bus size register d8 write dma channel 4 7 bus size register 19 read/write dma channel 0 3 chaining register d9 read/write dma channel 4 7 chaining register 00 read/write dma channel 0 target address, a0 a15 87 read/write dma channel 0 target address, a16 a23 10 read/write dma channel 0 target address, a24 a31 01 read/write dma channel 0 byte count, b0 b15 11 read/write dma channel 0 byte count, b16 b23 90 read/write dma channel 0 requester address, a0 a15 91 read/write dma channel 0 requester address, a16 a31 02 read/write dma channel 1 target address, a0 a15 83 read/write dma channel 1 target address, a16 a23 12 read/write dma channel 1 target address, a24 a31 03 read/write dma channel 1 byte count, b0 b15 13 read/write dma channel 1 byte count, b16 b23 92 read/write dma channel 1 requester address, a0 a15 93 read/write dma channel 1 requester address, a16 a31 b-1
M82380 appendix beports listed by function (continued) port address (hex) description dma controller 04 read/write dma channel 2 target address, a0 a15 81 read/write dma channel 2 target address, a16 a23 14 read/write dma channel 2 target address, a24 a31 05 read/write dma channel 2 byte count, b0 b15 15 read/write dma channel 2 byte count, b16 b23 94 read/write dma channel 2 requester address, a0 a15 95 read/write dma channel 2 requester address, a16 a31 06 read/write dma channel 3 target address, a0 a15 82 read/write dma channel 3 target address, a16 a23 16 read/write dma channel 3 target address, a24 a31 07 read/write dma channel 3 byte count, b0 b15 17 read/write dma channel 3 byte count, b16 b23 96 read/write dma channel 3 requester address, a0 a15 97 read/write dma channel 3 requester address, a16 a31 c0 read/write dma channel 4 target address, a0 a15 8f read/write dma channel 4 target address, a16 a23 d0 read/write dma channel 4 target address, a24 a31 c1 read/write dma channel 4 byte count, b0 b15 d1 read/write dma channel 4 byte count, b16 b23 98 read/write dma channel 4 requester address, a0 a15 99 read/write dma channel 4 requester address, a16 a31 c2 read/write dma channel 5 target address, a0 a15 8b read/write dma channel 5 target address, a16 a23 d2 read/write dma channel 5 target address, a24 a31 c3 read/write dma channel 5 byte count, b0 b15 d3 read/write dma channel 5 byte count, b16 b23 9a read/write dma channel 5 requester address, a0 a15 9b read/write dma channel 5 requester address, a16 a31 c4 read/write dma channel 6 target address, a0 a15 89 read/write dma channel 6 target address, a16 a23 d4 read/write dma channel 6 target address, a24 a31 c5 read/write dma channel 6 byte count, b0 b15 d5 read/write dma channel 6 byte count, b16 b23 9c read/write dma channel 6 requester address, a0 a15 9d read/write dma channel 6 requester address, a16 a31 c6 read/write dma channel 7 target address, a0 a15 8a read/write dma channel 7 target address, a16 a23 d6 read/write dma channel 7 target address, a24 a31 c7 read/write dma channel 7 byte count, b0 b15 d7 read/write dma channel 7 byte count, b16 b23 9e read/write dma channel 7 requester address, a0 a15 9f read/write dma channel 7 requester address, a16 a31 b-2
M82380 appendix beports listed by function (continued) port address (hex) description interrupt controller 20 write bank b icw1, ocw2, or ocw3 read bank b poll, interrupt request or in-service status register 21 write bank b icw2, icw3, icw4 or ocw1 read bank b interrupt mask register 22 read bank b icw2 28 read/write irq8 vector register 29 read/write irq9 vector register 2a reserved 2b read/write irq11 vector register 2c read/write irq12 vector register 2d read/write irq13 vector register 2e read/write irq14 vector register 2f read/write irq15 vector register a0 write bank c icw1, ocw2 or ocw3 read bank c poll, interrupt request or in-service status register a1 write bank c icw2, icw3, icw4 or ocw1 read bank c interrupt mask register a2 read bank c icw2 a8 read/write irq16 vector register a9 read/write irq17 vector register aa read/write irq18 vector register ab read/write irq19 vector register ac read/write irq20 vector register ad read/write irq21 vector register ae read/write irq22 vector register af read/write irq23 vector register 30 write bank a icw1, ocw2 or ocw3 read bank a poll, interrupt request oor in-service status register 31 write bank a icw2, icw3, icw4 or ocw1 read bank a interrupt mask register 32 read bank a icw2 38 read/write irq0 vector register 39 read/write irq1 vector register 3a read/write irq1.5 vector register 3b read/write irq3 vector register 3c read/write irq4 vector register 3d reserved 3e reserved 3f read/write irq7 vector register b-3
M82380 appendix beports listed by function (continued) port address (hex) description programmable interval timer 40 read/write counter 0 register 41 read/write counter 1 register 42 read/write counter 2 register 43 write control word register iecounter 0, 1, 2 44 read/write counter 3 register 47 write word register iiecounter 3 cpu reset 64 write cpu reset register (data-1111xxx0h) wait state generator 72 read/write wait state register 0 73 read/write wait state register 1 74 read/write wait state register 2 75 read/write refresh wait state register dram refresh controller 1c read/write refresh control register internal control and diagnostic ports 61 write internal control port 80 read/write internal diagnostic port 0 88 read/write internal diagnostic port 1 relocation register 7f read/write relocation register intel reserved ports 2a reserved 3d reserved 3e reserved 45 reserved 46 reserved 76 reserved 77 reserved 7d reserved 7e reserved cc reserved cd reserved b-4
M82380 appendix c pin descriptions the M82380 provides all of the signals necessary to interface it to an i386 processor. it has separate 32-bit address and data buses. it also has a set of control signals to support operation as a bus master or a bus slave. several special function signals exist on the M82380 for interfacing the system support peripherals to their respective system counterparts. following are the definitions of the individual pins of the M82380. these brief descriptions are provided as a reference. each signal is further defined within the sections which describe the associated M82380 function. a2-a31 i/o address bus this is the 32-bit address bus. the addresses are doubleword memory and i/o addresses. these are three-state signals which are active only during mas- ter mode. the address lines should be connected directly to the i386's local bus. be0 i/o byte-enable 0 be0 active indicates that data bits d0 d7 are being accessed or are valid. it is connected directly to the i386's be0 . the byte enable signals are active out- puts when the M82380 is in the master mode. be1 i/o byte-enable 1 be1 active indicates that data bits d8 d15 are be- ing accessed or are valid. it is connected directly to the i386's be1 . the byte enable signals are active only when the M82380 is in the master mode. be2 i/o byte-enable 2 be2 active indicates that data bits d15 d23 are be- ing accessed or are valid. it is connected directly to the i386's be2 . the byte enable signals are active only when the M82380 is in the master mode. be3 i/o byte-enable 3 be3 active indicates that data bits d24 d31 are be- ing accessed or are valid. the byte enable signals are active only when the M82380 is in the master mode. this pin should be connected directly to the i386's be3 . this pin is used for factory testing and must be low during reset. the m80386 drives be3 low during reset. d0 d31 i/o data bus this is the 32-bit data bus. these pins are active outputs during interrupt acknowledges, during slave accesses, and when the M82380 is in the master mode. clk2 i processor clock this pin must be connected to clk2. the M82380 monitors the phase of this clock in order to remain synchronized with the i386 processor. this clock drives all of the internal synchronous circuitry. d/c i/o data/control d/c is used to distinguish between i386 processor control cycles and dma or i386 processor data ac- cess cycles. it is active as an output only in the mas- ter mode. w/r i/o write/read w/r is used to distinguish between write and read cycles. it is active as an output only in the master mode. m/io i/o memory/io m/io is used to distinguish between memory and io accesses. it is active as an output only in the master mode. ads i/o address status this signal indicates presence of a valid address on the address bus. it is active as output only in the master mode. ads is active during the first t-state where addresses and control signals are valid. na i next address asserted by a peripheral or memory to begin a pipe- lined address cycle. this pin is monitored only while the M82380 is in the master mode. in the slave mode, pipelining is determined by the current and past status of the ads and ready signals. c-1
M82380 hold o hold request this is an active-high signal to the i386 processor to request control of the system bus. when control is granted, the i386 processor activates the hold ac- knowledge signal (hlda). hlda i hold acknowledge this input signal tells the dma controller that the i386 processor has relinquished control of the sys- tem bus to the dma controller. dreq (0 3, 5 7) i dma request the dma request inputs monitor requests from pe- ripherals requiring dma service. each of the eight dma channels has one dreq input. these active- high inputs are internally synchronized and priori- tized. upon reset, channel 0 has the highest priority and channel 7 the lowest. dreq4/irq9 i dma/interrupt re- quest this is the dma request input for channel 4. it is also connected to the interrupt controller via interrupt re- quest 9. this internal connection is available for dma channel 4 only. the interrupt input is active low and can be programmed as either edge of level trig- gered. either function can be masked by the appro- priate mask register. priorities of the dma channel and the interrupt request are not related but follow the rules of the individual controllers. note that this pin has a weak internal pull-up. this causes the interrupt request to be inactive, but the dma request will be active if there is no external connection made. most applications will require that either one or the other of these functions be used, but not both. for this reason, it is advised that dma channel 4 be used for transfers where a software request is more appropriate (such as memory-to- memory transfers). in such an application, dreq4 can be masked by software, freeing irq9 for other purposes. eop i/o end of process as an output, this signal indicates that the current requester access is the last access of the currently operating dma channel. it is activated when termi- nal count is reached. as an input, it signals the dma channel to terminate the current buffer and proceed to the next buffer, if one is available. this signal may be programmed as an asynchronous or synchro- nous input. eop must be connected to a pull-up resistor. this will prevent erroneous external requests for termina- tion of a dma process. edack (0 2) o encoded dma acknowl- edge these signals contain the encoded acknowledge- ment of a request for dma service by a peripheral. the binary code formed by the three signals indi- cates which channel is active. channel 4 does not have a dma acknowledge. the inactive state is indi- cated by the code 100. during a requester access, edack presents the code for the active dma chan- nel. during a target access, edack presents the inactive code 100. irq (11 23) i interrupt request these are active low interrupt request inputs. the inputs can be programmed to be edge or level sensi- tive. interrupt priorities are programmable as either fixed or rotating. these inputs have weak internal pull-up resistors. unused interrupt request inputs should be tied inactive externally. int o interrupt out int signals the i386 processor that an interrupt re- quest is pending. clkin i timer clock input this is the clock input signal to all of the M82380's programmable timers. it is independent of the sys- tem clock input (clk2). tout1/ref o timer 1 output/refresh this pin is software programmable as either the di- rect output of timer 1, or as the indicator of a refresh cycle in progress. as ref , this signal is active during the memory read cycle which occurs during refresh. tout2 /irq3 i/o timer 2 output/inter- rupt request3 this is the inverted output of timer 2. it is also con- nected directly to interrupt request 3. external hard- ware can use irq3 if timer 2 is programmed as out e 0 (tout2 e 1) tout3 o timer 3 output this is the inverted output of timer 3. c-2
M82380 ready i ready input this active-low input indicates to the M82380 that the current bus cycle is complete. ready is sam- pled by the M82380 both while it is in the master mode, and while it is in the slave mode. wsc (0 1) i wait state control wsc0 and wsc1 are inputs used by the wait-state generator to determine the number of wait states required by the currently accessed memory or i/o. the binary code on these ins, combined with the m/io signal, selects an internal register in which a wait-state count is stored. the combination wsc e 11 disables the wait-state generator. readyo o ready output this is the synchronized output of the wait-state generator. it is also valid during i386 processor ac- cesses to the M82380 in the slave mode when the M82380 requires wait states. readyo should feed directly the i386 processor's ready input. reset i reset this synchronous input serves to initialize the state of the M82380 and provides basis for the cpurst output. reset must be held active for at least 15 clk2 cycles in order to guarantee the state of the M82380. after reset, the M82380 is in the slave mode with all outputs except timers and interrupts in their inactive states. the state of the timers and in- terrupt controller must be initialized through soft- ware. this input must be active for the entire time required by the i386 processor to guarantee proper reset. cpurst o cpu reset cpurst provides a synchronized reset signal for the cpu. it is activated in the event of a software reset command, an i386 processor shut-down de- tect, or a hardware reset via the reset pin. the M82380 holds cpurst active for 62 clocks in re- sponse to either a software reset command or a shut-down detection. otherwise cpurst reflects the reset input. v cc a 5v input power v ss ground table 18. wait-state select inputs port wait-state registers select inputs address d7 d4 d3 d0 wsc1 wsc0 72h memory 0 i/o 0 0 0 73h memory 1 i/o 1 0 1 74h memory 2 i/o 2 1 1 disabled 1 1 m/io 10 c-3

M82380 appendix d M82380 system notes M82380 timer unit system notes the M82380 dma controller with integrated system peripherals is functionally inconsistent with the data sheet. this document explains the behavior of the M82380 timer unit and outlines subsequent limita- tions of the timer unit. this document also provides recommended workarounds. overview there are two areas in which the M82380 timer unit exhibits non-specified behavior: 1. mode 0 operation 2. write cycles to the M82380 timer unit mode 0 operation description for mode 0 operation, the M82380 timer is specified as follows: ``1. writing the first byte disables counting, out is set low immediately . . . '' due to mode 0 errata, this should read as follows: ``1. writing the first byte sets out low imme- diately. if the counter has not yet expired, writ- ing the first byte also disables counting. how- ever, if the counter has expired, writing the first count does not disable counting, although out still behaves correctly (set low immedi- ately).'' consequences software errors will occur if algorithms depend on the M82380 timer unit to stop counting after writing the first byte. thus, software that is based on the m8254 core will not function reliably on the M82380 timer unit. note, however, that the external signal of the timer behaves correctly. solution as long as software algorithms are aware of this be- havior, there should be no problems, as the external signal behaves correctly. long term plans currently, intel has no plans to fix this behavior of the M82380 timer unit. write cycles to the M82380 timer unit this errata applies only to slave write cycles to the M82380 timer unit. during these cycles, the data being written into the M82380 timer unit may be cor- rupted if clkin is not inhibited during a certain ``win- dow'' of the write cycle. description please refer to figure 1. during write cycles to the M82380 timer unit, the M82380 translates the 386dx interface signals such as ads , w/r , m/io , and d/c into several internal signals that control the operation of the internal sub- blocks (e.g., timer unit). the M82380 timer unit is controlled by such internal signals. these internal signals are generated and sampled with respect to two separate clock signals: clk2 (the system clock) and clkin (the M82380 timer unit clock). since the clkin and clk2 clock signals are used internally to generate control signals for the inter- face to the timer unit, some timing parameters must be met in order for the interface logic to function properly. those timing parameters are met by inhibiting the clkin signal for a specific window during write cy- cles to the M82380 timer unit. the clkin signal must be inhibited using external logic, as the gate function of the M82380 timer unit is not guaranteed to totally inhibit clkin. d-1
M82380 consequences this clkin inhibit circuitry guarantees proper write cycles to the M82380 timer unit. without this solution, write cycles to the M82380 tim- er unit could place corrupted data into the timer unit registers. this, in turn, could yield inaccurate results and improper timer operation. the proposed solution would involve a hardware modification for existing systems. solution a timing waveform (figure 2) shows the specific win- dow during which clkin must be inhibited. please note that clkin must only be inhibited during the window shown in figure 2. this window is defined by two ac timing parameters: t a e 9ns t b e 28 ns the proposed solution provides a certain amount of system ``guardband'' to make sure that this window is avoided. pal equations for a suggested workaround are also included. please refer to the comments in the pal codes for stated assumptions of this particular work- around. a state diagram (figure 3) is provided to help clarify how this pal is designed. figure 4 shows how this pal would fit into a system workaround. in order to show the effect of this work- around on the clkin signal, figure 5 shows how clkin is inhibited. note that you must still meet the clkin ac timing parameters (e.g., t 47 (min), t 48 (min)) in order for the timer unit to function properly. please note that this workaround has not been test- ed. it is provided as a suggested solution. actual solutions will vary from system to system. long term plans intel has no plans to fix this behavior in the M82380 timer unit. module timer 82380 fix flag '-r2','-q2','-f1', '-t4', '-w1,3,6,5,4,16,7,12,17,18,15,14' title 'M82380 timer unit clkin inhibit signal pal solution ' timer unit fix device 'p16r6'; `this pal inhibits the clkin signal (that comes from an oscillator) `during slave writes to the M82380 timer unit. ` `assumption: this pal assumes that an external system address ` decoder provides a signal to indicate that an 82380 ` timer unit access is taking place. this input ` signal is called tmr in this pal. this pal also ` assumes that this tmr signal occurs during a ` specific t-state. please see figure 3 of this ` document to see when this signal is expected to ` be active by this pal. ` ` `note: this pal does not support pipelined 82380 slave ` cycles. ` `(c) intel corporation 1989. this pal is provided as a proposed `method of solving a certain M82380 timer unit problem. this pal `has not been tested or validated. please validate this solution `for your system and application. ` d-2
M82380 `input pins` clk2 pin 1; `system clock reset pin 2; `microprocessor reset signal tmr pin 3; `input from address decoder, indicating `an access to the timer unit of the `82380. !rdy pin 4; `end of cycle indicator !ads pin 5; `address and control strobe clk pin 6; `phi2 clock w r pin 7; `write/read signal` nc1 pin 8; `no connect 0` nc3 pin 9; `no connect 1` gnda pin 10; `tied to ground, documentation only gndb pin 11; `output enable, documentation only clkin in pin 12; `input clkin directly from oscillator `output pins` q 0 pin 18; `internal signal only, fed back to `pal logic` clkin out pin 17; `clkin signal fed to 82380 timer unit inhibit pin 16; `clkin inhibit signal s0 pin 15; `unused state indicator pin s1 pin 14; `unused state indicator pin `declarations` valid ads 4 ads & clk ; `ads # sampled in phi1 of 386dx t-state valid rdy 4 rdy & clk ; `rdy # sampled in phi1 of 386dx t-state timer acc 4 tmr & clk ; `timer unit access, as provided by `external address decoder ` state diagram [ inhibit, s1, s0 ] state 000: if reset then 000 else if valid ads&w r then 001 else 000; state 001: if reset then 000 else if timer acc then 010 else if !timer acc then 000 else 001; state 010: if reset then 000 else if clk then 110 else 010; state 110: if reset then 000 else if clk then 111 else 110; d-3
M82380 state 111: if reset then 000 else if clk then 011 else 111; state 011: if reset then 000 else if valid rdy then 000 else 011; state 100: if reset then 000 else 000; state 101: if reset then 000 else 000; equations q 0: 4 clkin in ; `latched incoming clock. this signal is used `internally to feed into the mux-ing logic` clkin out : 4 (inhibit & clkin out & !reset) 0 (!inhibit & q 0 & !reset); `equation for clkin out. this `feeds directly to the 82380 timer unit.` end page 1 abel(tm) 3.10 - document generator 30-june 89 03:17 pm 82380 timer unit clkin inhibit signal pal solution equations for module timer 82380 fix device timer unit fix - reduced equations: !inhibit : 4 (!clk & !inhibit # clk&s0 # reset # !s1); !s1 : 4 (reset # inhibit & !s1 # clk & !inhibit & ! e rdy&s0&s1 # !clk & !s1 # !s1 & !tmr # !s0 & !s1); !s0 : 4 (reset # inhibit & !s1 # clk & !inhibit & ! e rdy&s1 # !clk & !s0 # !inhibit & !s0 & s1 # s0 & !s1 # !s1&!w r # e ads & !s1); d-4
M82380 !q 0: 4 (!clkin in); !clkin out : 4 (reset # !clkin out & inhibit # !inhibit & !q 0); page 2 abel(tm) 3.10 - document generator 30-june 89 03:17 pm 82380 timer unit clkin inhibit signal pal solution chip diagram for module timer 82380 fix device timer unit fix p16r6 271070 b6 end of module timer 82380 fix 271070 b7 figure 1. translation of i386 tm dx signals to internal M82380 timer unit signals d-5
M82380 figure 2. M82380 timer unit write cycle 271070 b8 t a e 9ns t b e 28 ns d-6
M82380 [ inhibit, s1, s0 ] 271070 b9 figure 3. state diagram for inhibit signal 271070 c0 note: this solution does not support pipelined M82380 slave cycles. figure 4. system with M82380 timer unit ``inhibit'' circuitry d-7
M82380 271070 c1 figure 5(a). inhibited clkin in an M82380 timer unit and clkin minimum high time 271070 c2 figure 5(b). inhibited clkin in an M82380 timer unit and clkin minimum low time intel corporation, 2200 mission college blvd., santa clara, ca 95052; tel. (408) 765-8080 intel corporation (u.k.) ltd., swindon, united kingdom; tel. (0793) 696 000 intel japan k.k., ibaraki-ken; tel. 029747-8511

▲Up To Search▲

Price & Availability of M82380

	To Download M82380 Datasheet File
If you can't view the Datasheet, Please click here to try to view without PDF Reader .